You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Matthias Bläsing <mb...@doppel-helix.eu> on 2019/10/18 19:55:19 UTC
[PluginPortal] Implement OAuth2 based authentication in PP3?
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PluginPortal] Implement OAuth2 based authentication in PP3?
Posted by Geertjan Wielenga <ge...@apache.org>.
Wow, thanks for this great work, it is a big step forward.
Gj
On Sat, Oct 26, 2019 at 8:53 PM Matthias Bläsing <mb...@doppel-helix.eu>
wrote:
> Hi again,
>
> so I reactivated my PHP-foo and this is the result:
>
> https://github.com/apache/netbeans-tools/pull/15
>
> The PR holds a full implementation of changes I prototyped in java.
>
> For the "what was done", please see the PR. The portal can be tested
> at:
>
> https://doppel-helix.eu/pp3/
>
> Greetings
>
> Matthias
>
>
> Am Freitag, den 18.10.2019, 21:55 +0200 schrieb Matthias Bläsing:
> > 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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [PluginPortal] Implement OAuth2 based authentication in PP3?
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi again,
so I reactivated my PHP-foo and this is the result:
https://github.com/apache/netbeans-tools/pull/15
The PR holds a full implementation of changes I prototyped in java.
For the "what was done", please see the PR. The portal can be tested
at:
https://doppel-helix.eu/pp3/
Greetings
Matthias
Am Freitag, den 18.10.2019, 21:55 +0200 schrieb Matthias Bläsing:
> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PluginPortal] Implement OAuth2 based authentication in PP3?
Posted by Geertjan Wielenga <ge...@apache.org>.
Understood. Yes, let's wait and get some more responses from people before
you spend time implementing this.
Gj
On Sat, Oct 19, 2019 at 12:06 PM Matthias Bläsing <mb...@doppel-helix.eu>
wrote:
> Hi,
>
> Am Samstag, den 19.10.2019, 11:54 +0200 schrieb Geertjan Wielenga:
> > 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 <
> mblaesing@doppel-helix.eu> wrote:
> >
> > > [Oauth "code" flow based authentication, prototyped in Java]
>
> not directly, as my prototype code is Java and the PluginPortal is
> implemented in PHP. I'm able to code in PHP, but I don't like it and
> for prototyping (ok this is ironic) I prefer Java. The code I produced
> demonstrates the steps that are necessary to implement the
> authentication flow and demonstrate, that it is realisticly usable.
>
> Before I go on to implement it in PHP I want to know if there is
> interest, as it will invalidate all current accounts and take time to
> do.
>
> Greetings
>
> Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [PluginPortal] Implement OAuth2 based authentication in PP3?
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Samstag, den 19.10.2019, 11:54 +0200 schrieb Geertjan Wielenga:
> 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 <mb...@doppel-helix.eu> wrote:
>
> > [Oauth "code" flow based authentication, prototyped in Java]
not directly, as my prototype code is Java and the PluginPortal is
implemented in PHP. I'm able to code in PHP, but I don't like it and
for prototyping (ok this is ironic) I prefer Java. The code I produced
demonstrates the steps that are necessary to implement the
authentication flow and demonstrate, that it is realisticly usable.
Before I go on to implement it in PHP I want to know if there is
interest, as it will invalidate all current accounts and take time to
do.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PluginPortal] Implement OAuth2 based authentication in PP3?
Posted by Geertjan Wielenga <ge...@apache.org>.
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 <mb...@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>