Thanks for this research, can it be integrated into a pull request in the pp3 tool in apache-netbeans-tools repo?
Gj On Fri, 18 Oct 2019 at 21:55, Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > 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 > > > >
