Hi, it was raised on this list already and I agree, that tying the Plugin Portal to a Google Account sound like a not too good idea. I for example use my google account only for a minimal set of services and don't see why that should change.
At this point Plugin Portal 3 implements an OpenID Connect Implicit Flow for Authentication. But I think other OAuth2 based authentication providers can be integrated with to much pain. I prototyped the idea as a dropwizard java application, that only implements the authentication flow. That application currently supports: - Google - GitHub - Amazon Other Authentication providers can be integrated. Required is, that the authentication provider uses OAuth2 and provides a Userinfo endpoint, that returns: - a stable ID - Name - Email All providers listed above follow (loosly) the OpenID Connect "code" flow. >From my reading of https://oauth.apache.org/api.html it should be possible to implement a authentication for apache committer account (if really requested). The sample code an be foud here: https://github.com/matthiasblaesing/PluginPortalDemo You can test the authentication flow youself. I made the application available on: https://doppel-helix.eu:9000/ Be warned: all requests are logged. I will not be able to see your passwords (that is the whole point of the OAuth protocol), but the requested information (profile data). 1. Open https://doppel-helix.eu:9000/oauth/ You will get a JSON document, that lists als authentication providers I configured. Code: https://github.com/matthiasblaesing/PluginPortalDemo/blob/master/src/main/java/eu/doppel_helix/dev/pluginportaldemo/resources/AuthenticationResource.java#L69 2. From that list get the id of the provider you want to test and open https://doppel-helix.eu:9000/oauth/start/<id> For example to authenticate with github you would run: https://doppel-helix.eu:9000/oauth/start/github Code: https://github.com/matthiasblaesing/PluginPortalDemo/blob/master/src/main/java/eu/doppel_helix/dev/pluginportaldemo/resources/AuthenticationResource.java#L75 3. Now you will be redirected to the authentication provider. If you have not yet signed in to your account, you will be asked to do so. This is communication between you and the authentication provider, so my code will not be involved and thus not be able to access your password. After sign in you will be asked if you consent, that the Demo Application accesses your profile data (depending on authentication provider this is differently worded). If you consent, you will be redirect back to my code. 4. You are redirected to https://doppel-helix.eu:9000/oauth/code The authentication provider calls the above mentioned URL with a "code". That code is exchanged for an access token: Code: https://github.com/matthiasblaesing/PluginPortalDemo/blob/master/src/main/java/eu/doppel_helix/dev/pluginportaldemo/resources/AuthenticationResource.java#L114 With the access token the userinfo endpoint is contacted to query the userdata: Code: https://github.com/matthiasblaesing/PluginPortalDemo/blob/master/src/main/java/eu/doppel_helix/dev/pluginportaldemo/resources/AuthenticationResource.java#L126 The userdata is converted to a unified format and returned: Code: https://github.com/matthiasblaesing/PluginPortalDemo/blob/master/src/main/java/eu/doppel_helix/dev/pluginportaldemo/resources/AuthenticationResource.java#L133 At this point the session could be updated to the logged in state. This was done as a java application to keep my sanity - but it can be (and I'm willing to do that) transferred to PHP. I will only do that if there is agreement, that this is a good idea, as this also needs updates to the persistent data. We can't use the email as an identifier anymore (but even google says, that the email can change, while their provided ID will be constant), so we need to indirect that to a user table: user: id - internal id idp_id - ID of the identity provider idp_user_id - ID the identity provider assigned to the user name - Real name (if needed) nick - a choosen and displayed nickname email - Emailadress from last login (if needed) id would be the primary key, idp_id and idp_user_id form a compound key and must be unique too. Thank you to anyone, that made it to this point and/or tested the sample. I'd like to hear, what you think. Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
