Community
Participate
Working Groups
For the error reporting as well as custom applications I'd like to provide a "Sign in with Eclipse" button. Once pressed, a normal authentication process goes on that authenticates the user and then redirects the user back to my application's website. Is that currently possible? I'd like this service to be integrated into the Eclipse IDE as well as on the error reporting web-pages. I'd need access to the user name and email in order to send user's a mail if one of their bugs has been fixed etc. What do you think? How difficult would it be to set up an OAuth or Open ID Connect workflow?
Marcel, We're currently working on a solution that will allow Eclipse projects to store user data on our servers in an authenticated fashion, using a restful service. We're ironing out details -- perhaps we can use this bug to discuss the effort?
Just adding: Storing in eclipse.org servers is nice. But using eclipse.org as oauth service is the point I'm more interested in and which is more flexible. I'd love to use that for some of our crowd sourcing ideas and "contributing to the Eclipse community with an eclipse.org account" would just be a big marketing plus.
Oh, I understand.
(In reply to Marcel Bruch from comment #2) > Just adding: > > Storing in eclipse.org servers is nice. But using eclipse.org as oauth > service is the point I'm more interested in and which is more flexible. > > I'd love to use that for some of our crowd sourcing ideas and "contributing > to the Eclipse community with an eclipse.org account" would just be a big > marketing plus. Marcel, can you give an example of where the 'Sign in with Eclipse' button might be used. What type of web site or service? On the idea of Eclipse Foundation providing a central storage on eclipse.org, do you think Code Recommenders or Error Reporting would make use of that type of service?
Created attachment 256190 [details] Example Screenshot using OAuth inside Eclipse (In reply to Ian Skerrett from comment #4) > Marcel, can you give an example of where the 'Sign in with Eclipse' button > might be used. What type of web site or service? We currently support "Sign in with Google"/"Sign in with Github" inside Eclipse to authenticate our users. I plan to use it to share code snippets, @Nullable annotations and many things more. These systems need some authentication and I can imagine that "Sign in with Eclipse" would be a great alternative to Sign in with Github. To give an eclipse.org example: For the error reporting I'd like to give user access to problems they reported, the current state of these problems and general statistics. To do so, we'd need users to authenticate and save a secret on the (IDE) client side. For every data point or web connection they make, they would authenticate using the OAuth token. Absolutely save and straight forward to use. > On the idea of Eclipse Foundation providing a central storage on > eclipse.org, do you think Code Recommenders or Error Reporting would make > use of that type of service? For most of the data I have in mind (e.g. thousands of error reports) this does not make sense. They would rather be stored on the error reporting server's database. However, I can imagine to store some user preferences in the central service which would be loaded from remote if the user set's up a fresh eclipse. This, again, would need some authentication (if this supports Oauth, I'd be happy :-)). But without thinking too much about it: I wouldn't need much information to be stored there. Likely a few preferences. I usually need the name and the email address of a user and his roles ("committer", "user") (e.g. to notify him about important news, bugs, fixes etc.). But I need to make sure I can link an error report with a user. Thus, I'm more interested in authentication than storing some small amounts of data in a central service. The ability to store values in a eclipse.org-side database, however, is likely a useful thing.
(In reply to Marcel Bruch from comment #5) > Created attachment 256190 [details] > Example Screenshot using OAuth inside Eclipse > > (In reply to Ian Skerrett from comment #4) > > Marcel, can you give an example of where the 'Sign in with Eclipse' button > > might be used. What type of web site or service? > > We currently support "Sign in with Google"/"Sign in with Github" inside > Eclipse to authenticate our users. Marcel, sorry if I am dense but when you say 'We currently support...' what is 'we'? > > > To give an eclipse.org example: For the error reporting I'd like to give > user access to problems they reported, the current state of these problems > and general statistics. To do so, we'd need users to authenticate and save a > secret on the (IDE) client side. For every data point or web connection they > make, they would authenticate using the OAuth token. Absolutely save and > straight forward to use. Make sense. I'd like to get to the point where an Eclipse user does on login and can get access to a number of different eclipse.org services, including marketplace, error reporting, a new idea of a central store, maybe Mylyn, etc. > > > On the idea of Eclipse Foundation providing a central storage on > > eclipse.org, do you think Code Recommenders or Error Reporting would make > > use of that type of service? > > For most of the data I have in mind (e.g. thousands of error reports) this > does not make sense. They would rather be stored on the error reporting > server's database. > > However, I can imagine to store some user preferences in the central service > which would be loaded from remote if the user set's up a fresh eclipse. > This, again, would need some authentication (if this supports Oauth, I'd be > happy :-)). OK > > But without thinking too much about it: I wouldn't need much information to > be stored there. Likely a few preferences. We are hoping to be able to use Oomph to store preferences so ideally you would get this as part of oomph. > > > The ability to store values in a eclipse.org-side database, however, is > likely a useful thing. I hope so. It would be nice to find some examples.
> For most of the data I have in mind (e.g. thousands of error reports) this > does not make sense. They would rather be stored on the error reporting > server's database. I really do not want to manage/control more than I already have, but I don't think having massive amounts of Eclipse user data stored on a project vserver is a viable solution. For instance, the babel community translation service stores gigabytes of user-submitted data, and the data backend is managed by webmaster (we create backups and have a restore strategy). If the data strored is discardable, then I think there's nothing to do here. But if it's important for Eclipse users, we may want to think about this.
(In reply to Denis Roy from comment #7) > > For most of the data I have in mind (e.g. thousands of error reports) this > > does not make sense. They would rather be stored on the error reporting > > server's database. > > I really do not want to manage/control more than I already have, but I don't > think having massive amounts of Eclipse user data stored on a project > vserver is a viable solution. A few thoughts: 1. The data is not "mission critical", i.e., a complete loss would be a pity but no drama 2. It's no "user data" in the way that Eclipse users need access to it. It's more like a large log file. 3. I do simple database dumps from time to time. In case the server database get's corrupted, we can rebuild "last week's status" which is fine for me. 4. I don't want to create additional workloads for Webmasters [1]. However, since the backup is stored on the vserver's hard drive it might make sense to store a copy elsewhere (depending on how your vserver's work). The raw data backup is a 1GB zip file ATM. Let me know if there is a network drive I could send the backup file to. If there is no space for weekly 1GB backups, I can reduce it to 10MB zip file (just the essence from the data). Let me know what's possible. [1] https://twitter.com/droy_eclipse/status/596398539871158272
(In reply to Ian Skerrett from comment #6) > Marcel, sorry if I am dense but when you say 'We currently support...' what > is 'we'? We is Codetrails. Egit/Gerrit and Mylyn have support for Oauth / OpenId but I've no details. > Make sense. I'd like to get to the point where an Eclipse user does on login > and can get access to a number of different eclipse.org services, including > marketplace, error reporting, a new idea of a central store, maybe Mylyn, > etc. I've no idea what you have in mind but your SSO is a/one way Eclipse.org websites can provide additional services to Eclipse users. Oauth or OpenID give applications and websites the ability to provide additional services for Eclipse Users. FWIW, JBoss Keycloak can integrate with LDAP which is (AFAIK) the user backend of eclipse.org (?). If I could get more details about the LDAP and access means I could set up an experimental service (for testing). Let me know if there is interest.
> What do you think? I like the basic idea of this. > How difficult would it be to set up an OAuth or Open ID > Connect workflow? I'm going through the security docs... But don't expect this to be deployed in the following weeks. Maybe 2016/Q1.
(In reply to Denis Roy from comment #10) > I'm going through the security docs... But don't expect this to be deployed > in the following weeks. Maybe 2016/Q1. Denis, would you support a quick prototype based on Red Hat Keycloak? Keycloak can bind to LDAP as backend and does all the OAuth stuff we'd need. To get the prototype up and running, I'd need some support to the binding Keycloak with LDAP (Schema, base dn for user auth etc.) I'd setup the prototype on the recommenders vm first just to see if it works.
Created attachment 256897 [details] LDAP settings to complete Just to give you some sense of what would be needed. The screenshot shows the configuration options. I guess this makes clear what would be needed to set up the prototype.
I appreciate your willingness to help -- but for security reasons project vservers are not on the same physical network as our authentication services, and we don't want a project server handling authentication.
Hi guys, this is Alex from the Vorto project team. I am also interested in a SSO service whereby users wanting to upload information models via the Information Model Repository service need to authenticate against Eclipse first. I am currently only interested in authenticating users, not so much in authorization at this stage yet, but i can see it becoming an issue at a later point of time for sure. Is there a way for me now to authenticate users against Eclipse from my web application already ? Cheers, Alex
> Is there a way for me now to authenticate users against Eclipse from my web > application already ? This is currently not possible, but this bug is requesting oAuth to do just that.
Any opinions on oAuth 1 vs. oAuth 2? Seems there was a battle a few years ago, but 2 seems to be in RFC proposal: http://tools.ietf.org/html/rfc6749 oAuth 2 seems to have plenty of API support: http://oauth.net/2/ I'll continue under the assumption that oAuth 2 will give us all we need.
v2 is the way to go. OAuth1 attempted to provide a universal solution but was inflexible. OAuth2 simplified the approach but abandoned the universal solution, which means clients have to have provide specific support for each provider.
OAuth v1.0a is legacy and shouldn't be used in new apps, please support OAuth v2. Thanks!
Open ID Connect for sure (aka oauth 2)
+1 for providing an OAuth 2 identity provider at Eclipse. It would be great if we could use it in the IoT project sandbox servers for leshan, Californium, Vorto repository and (later) Hono.
Denis, can you give some indication where on the priority list this feature request currently is? In August 2015 the estimate was "Maybe 2016/Q1".
We obviously missed our Q1 target, so re-targetting for Q2 (Apr-June).
I’ve been looking at three different server-side solutions, but haven’t gotten far enough to make a recommendation. In thinking about the USS SDK, and allowing other webapps like Mattermost and Tuleap, I saw the principle requirements as being: 1. It should be straightforward to request an application configuration E.g., Instagram is easy: https://weblizar.com/wp-content/uploads/2015/05/5-fill-the-register-client-form.png 2. It should be straightforward for the EF to revoke an application 3. The solution should support the normal OAuth client flows 4. There should be little other change required of the foundation's current setup (e.g., sign-on screens) I took a look at using Keycloak too. As Marcel noted above, it's a standalone authorization server that can act as an OAuth solution and authenticate against LDAP. The attraction of Keycloak is that it's a turn-key solution. But Keycloak doesn't really have documentation on setting it up as a plain OAuth service, and the tutorials I found didn't go into detail. It's an SSO/IDM solution that also happens to do OAuth, and so they use their own terminology and the mapping isn't straightforward. The process to add a new authorization requestor (e.g., the Mattermost installation, or Tuleap, or the USS-SDK) is unclear. And although Keycloak supports authenticating against LDAP, it seems to import from LDAP rather than federate against the LDAP — it’s not clear what’s considered the source of truth (e.g., when I change my LDAP password, does Keycloak take it?). Keycloak also seems to want to handle authentication (i.e., the login screen), which I suppose may be ok. I was trying to figure out where to define scopes, etc. My concerns with Keycloak are that it doesn't seem to offer #1 or #2, and seems to want to manage the sign-on process too (which may not be a bad thing?). And several OAuth libraries know how to deal with Keycloak directly. There are two PHP libraries that sound promising, but neither support authenticating with LDAP out of the box and will require some development work to integrate with LDAP. * http://github.com/bshaffer/oauth2-server-php.git Has an open ticket about LDAP integration; thinking it might be straightforward * http://github.com/thephpleague/oauth2-server.git
Thanks, Brian. api.eclipse.org is running the latest Drupal 7, and I remember Chris Guindon saying we could leverage some built-in modules to do this. I will let him comment further when he's back from vacation.
(In reply to Denis Roy from comment #24) > Thanks, Brian. api.eclipse.org is running the latest Drupal 7, and I > remember Chris Guindon saying we could leverage some built-in modules to do > this. I will let him comment further when he's back from vacation. (In reply to Brian de Alwis from comment #23) > I’ve been looking at three different server-side solutions, but haven’t > gotten far enough to make a recommendation. > > In thinking about the USS SDK, and allowing other webapps like Mattermost > and Tuleap, > I saw the principle requirements as being: > > 1. It should be straightforward to request an application configuration > E.g., Instagram is easy: > https://weblizar.com/wp-content/uploads/2015/05/5-fill-the-register-client- > form.png > > 2. It should be straightforward for the EF to revoke an application > > 3. The solution should support the normal OAuth client flows > > 4. There should be little other change required of the foundation's > current setup (e.g., sign-on screens) > > I took a look at using Keycloak too. As Marcel noted above, it's a > standalone authorization server that can act as an OAuth solution and > authenticate against LDAP. The attraction of Keycloak is that it's a > turn-key solution. > > But Keycloak doesn't really have documentation on setting it up as a plain > OAuth service, and the tutorials I found didn't go into detail. It's an > SSO/IDM solution that also happens to do OAuth, and so they use their own > terminology and the mapping isn't straightforward. The process to add a new > authorization requestor (e.g., the Mattermost installation, or Tuleap, or > the USS-SDK) is unclear. And although Keycloak supports authenticating > against LDAP, it seems to import from LDAP rather than federate against the > LDAP — it’s not clear what’s considered the source of truth (e.g., when I > change my LDAP password, does Keycloak take it?). Keycloak also seems to > want to handle authentication (i.e., the login screen), which I suppose may > be ok. I was trying to figure out where to define scopes, etc. > > My concerns with Keycloak are that it doesn't seem to offer #1 or #2, and > seems to want to manage the sign-on process too (which may not be a bad > thing?). And several OAuth libraries know how to deal with Keycloak > directly. > > > There are two PHP libraries that sound promising, but neither support > authenticating with LDAP out of the box and will require some development > work to integrate with LDAP. > > * http://github.com/bshaffer/oauth2-server-php.git > Has an open ticket about LDAP integration; thinking it might be > straightforward > > * http://github.com/thephpleague/oauth2-server.git There is a drupal module that provides OAuth2 server functionality based on the oauth2-server-php library that Brian listed earlier: https://www.drupal.org/project/oauth2_server Documentation page: https://www.drupal.org/node/1938218 When should we validate against ldap? Is it only on a password grand? I doubt we are going to use this type of Authorization since we don't want 3rd party apps to ask for a username/password. Please correct me if I am wrong but my understanding of oAuth is that the user needs to be logged in to the server before he can allow an application to access some portion of his account. If he is not logged in, the oAuth server should prompt a login form first? If this is the case, our drupal user login form already validate the users credentials with LDAP. I am moving our site_login to a new drupal site: Bug 492923 - Create new user dashboard/site_login drupal site I am thinking that we could use this new website to work on this bug. I could get a basic drupal site up with the oauth2_server module installed to get us started.
I was thinking about this on my way home after writing my last comment and I have a question for you Brian. Does it matter where we host the oAuth server? Should we install the oAuth server on api.eclipse.org since this is where apps will make oAuth authenticated requests to our api? If the oAuth server is hosted on api.eclipse.org, users will need to login to api.eclipse.org to revoke/approve access to applications that they previously approved. If this is true, I am questioning the value of building this user/dashboard site outside of api.eclipse.org (Bug 492923 - Create new user dashboard/site_login Drupal site). To me, it makes more sense to have everything in once central location and I don't want our users to go to user.eclipse.org to update their profile information and then ask them to go to api.eclipse.org to manage their list of approved apps. I might be missing something and there might be some value for separating the two. I am looking for some feedback to get a clear understanding of the best solution for our users. The user experience is very important to me and I want to make sure we always consider this while building this.
> Does it matter where we host the oAuth server? Should we install the > oAuth server on api.eclipse.org since this is where apps will > make oAuth authenticated requests to our api? There's a difference between authentication and authorization. OAuth deals with authorization (the user grants an application permission to access some subset of their data and to act on their behalf). As part of obtaining authorization, the OAuth layer may deem it necessary to authenticate the user too. Whether the login page is hosted on api.eclipse.org doesn't matter in theory, but it is better to look legitimate. To that end, I think there is some value in putting the account auth and profile manipulation on a different host ({user|login|accounts}.eclipse.org) from the actual services ({api|bugzilla|mattermost|tuleap}.eclipse.org). It also promotes that there is conceptual separation between authorization grants and the services that operate on the users behalf. And although you didn't ask, I mildly prefer accounts.eclipse.org to user.eclipse.org, but login.eclipse.org is pretty good for just the login page.
As discussed in bug 476927, Tuleap is now ready to get connected to Foundation's OpenIdConnect server when it's ready. Denis, do you think it might be ready for EclipseCon France, 9/10 june ?. No hurry there, it's to anticipate the communication we will have with users that might be interested to jump start then.
We *might* have something beta/staging for experimentation purposes, but I don't think we'll have something production within that timeframe. ChrisG can comment further if I'm off the mark.
(In reply to Denis Roy from comment #29) > We *might* have something beta/staging for experimentation purposes, but I > don't think we'll have something production within that timeframe. ChrisG > can comment further if I'm off the mark. I made some good progress this week. I have a working prototype with oAuth and openid on my local environment. The current setup is has follow: oAuth Server (Authentication, this is the new user dashboard site): ------------------------------------------------------------------- Required modules: 1) https://www.drupal.org/project/oauth2_server with https://github.com/bshaffer/oauth2-server-php 2) https://www.drupal.org/project/openid_connect_sso Client (For this example, we are using api.eclipse.org): ---------------------------------------------------------------------------------------- Required modules: 1) https://www.drupal.org/project/openid_connect 2) https://www.drupal.org/project/openid_connect_sso This allows us to confirm the identity a user on our oAuth Server. For example, the user will click the login link on api.eclipse.org. The user is sent to the user dashboard, if the user is not logged in, he will be asked to login to the user dashboard site. After, a successful login, the user dashboard will confirm the identity of the user for api.eclipse.org. This is currently working for new users but for existing users on api.eclipse.org, I will need to create a batch script that will map the identity of each user. In drupal this is done with the authmap table. aid, uid, authname, module '2', '9', '7', 'openid_connect_generic' This is copy of the authmap table. This means that user 9(me) is user 7(me) on user.eclipse.org. My next step is to use oAuth/openid authentication with api.eclipse.org REST server. Once this is done, I will make this available on a staging server. Brian, do you think this will be enough to get you started with the oAuth implementation for the Eclipse USS SDK?
Chris, do you need examples of how other providers are doing it? I can share how it works with Launchpad.net as a provider, to log on Stackoverflow or opensource.com
(In reply to Christopher Guindon from comment #30) > Brian, do you think this will be enough to get you started with the oAuth > implementation for the Eclipse USS SDK? Hmm, I'm missing some pieces. I need to know: 1. the url to initiate the authorization flow (https://api.eclipse.org/oauth2/authorize?) 2. how to request an application client id + secret, with a redirect_url 3. the granularity and mapping of scopes to USS application buckets With regards to #3, we could just have a single scope for the USS, so any application an read and write across any of the user's USS buckets, and use the application token (e.g., MPC, Oomph Prefs) to obscure the bucket names. Or we could have finer-grained scopes, such as a 1-1 mapping between a scope and a USS application token. This matters as it determines what the user will see on an authorization request.
This has been fully implemented. Starting today, we will start migrating our drupal sites to use openid connect to login to our sites. This will improve security since we will no longer have a login form on those sites. We are using openid connect right now on api.eclispe.org to verify the identity of the user. I am currently on vacation right now but once I get back, I plan on updating all of our Drupal sites to start using accounts.eclipse.org for authentication. Brian has successfully used oAuth2 to make authenticated request to our staging server for api.eclipse.org with Eclipse USS SDK. There is still lots of work to do on his end but we do know that the service is working. The code is now on production and I have sent him the required information to make requests on production (clientid, secret and redirect_url). For the moment, we do not plan on making this a self-serve service. If you are interested in using our openid connect service to verify the identity of an eclipse user, please send an e-mail to webdev@eclipse.org with the redirect url that you are planing to use in your application. I should start replying to these requests next week! I have to say this has been a really enjoyable experience. I have learned a lot in the last two months. Thank you everyone for your patience!
(In reply to Christopher Guindon from comment #33) > > For the moment, we do not plan on making this a self-serve service. If you > are interested in using our openid connect service to verify the identity of > an eclipse user, please send an e-mail to webdev@eclipse.org with the > redirect url that you are planing to use in your application. I should start > replying to these requests next week! Before we start adding any clients/users of the service I think we need to have a written policy on who can become clients and under what conditions will a client id be revoked.
I'd like to migrate AERI'S web ui to use the Eclipse OAuth service. Do we need a written policy for this use case? If not, can you provide me with a key, secret, url? Do you require a callback url? If so, do you allow sub-urls? If so, can we use dev.eclipse.org/recommenders/? With that I could use the same app to authenticate reviewers and reporters. Thanks, Marcel
(In reply to Ian Skerrett from comment #34) > (In reply to Christopher Guindon from comment #33) > > > > For the moment, we do not plan on making this a self-serve service. If you > > are interested in using our openid connect service to verify the identity of > > an eclipse user, please send an e-mail to webdev@eclipse.org with the > > redirect url that you are planing to use in your application. I should start > > replying to these requests next week! > > > Before we start adding any clients/users of the service I think we need to > have a written policy on who can become clients and under what conditions > will a client id be revoked. +1 but we should open a bug for this. I will do so.
Chris and I have started drafting this up: https://wiki.eclipse.org/OpenID
