Second attempt to implement OAuth authentication scheme in Gerrit

[David Ostrovsky]

After abandoning the approach to support one single OAuth authentication

scheme in Gerrit core, revamped attempt was started to support multiple

OAuth providers.

The idea is to restrict the core to only expose OAuth extension point and

use Gerrit plugin concept to provide support for multiple OAuth providers,

like it was done with Gerrit scripting plugin providers.

This change exposes such extension point [1] and offer provider selection

dilaog in case multiple OAuth provider plugins were deployed: [2].

Google OAuth2 provider plugin is available [3] that depends on this extension

point: [2]. Further OAuth provider plugins will follow.

TODO:

* support anonymous browsing, with redirect to login dialog when required

* support linking different OAuth identities to existing account

Are we done? For new sites yes, for existing sites, that depend on OpenID, not.

Problem:

Unfortunately this is still not sufficient migration path for Gerrit installations that

are using OpenID atm. What is needed is hybrid OpenID/OAuth authentication

scheme. This authentication option is indispensable for all Gerrit installations

in the wild that currently depend on OpenID, and with Google's end of life of

OpenID are screwed up, as only part of their user base is using deprecated

OpenID provider, while a substantial part of their user base is still using sane

OpenID providers.

Solution:

Offer aforementioned hybrid OpenID/OAuth authentication option and support

linking user identities across different authentication scheme (OpenID -> Oauth).

Ideally, this feature should be available (and released) before April 20, 2015.

[1] https://gerrit-review.googlesource.com/65101

[2] http://imgur.com/KMfXRSW

[3] https://github.com/davido/gerrit-google-oauth-provider

[Luca Milanesio]

Hi David,

well done in taking one step forward my initial approach: at least 57 iterations and 7 months of work have helped to understand the direction to take.

I definitely like the new revamped implementation but I would outline one risk: moving forward with a “perfect solution for all” and being stuck again for X mounts and YY iterations :-(

I would propose to move quickly to a simple and clean solution, even if it is not perfect at all but *good enough* to be safely rolled out to production.

Why don’t we leave the TODO items to a later change and get this new approach approved quickly?

April is approaching fast … only 1 week to March :-O

*We do need* some initial review from some Googlers (Shawn would be best) to get an early feedback on the approach … which seems to be aligned with the suggestions and concerns of the initial implementation.

Once the new change is merged, I would be *more than happy* to remove lots of complicated code on the github-plugin and release the first OAuth implementation plugin for Gerrit :-)

What I really like of [1] is that does not require any change to Gerrit libraries dependencies, which makes it easier and safer to approve and deploy.

Thanks again David :-)

Luca.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dariusz Luksza]

Awesome work David!

I'm missing one thing here, the git interactions with gerrit. From
what I see you focus on web ui authentication. What about fetch/push
over http and ssh? Would be also possible to use OAuth there?

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to repo-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Best regards

GSM: +49 017 445 41235
Blog: http://luksza.org http://javablog.pl
LinkedIn: http://linkedin.com/in/dariuszluksza

[Luca Milanesio]

Hi Dariusz,
thanks for raising that point :-)

With existing OpenID authentication you basically have a generated HTTP password stored in Gerrit and with other OAuth providers you have a similar approach (OAuth persistent code).
With regards to Git/SSH, things are different as you are not authenticated against your Realm but against a published SSH public key. The point would then be different and would relate to Group Backend implementation and associated authorisation.

Following my earlier suggestion ... I would leave the Git/HTTP and Git/SSH to a later change ;-)

Luca.

[Dariusz Luksza]

On Wed, Feb 25, 2015 at 9:34 AM, Luca Milanesio
<luca.mi...@gmail.com> wrote:
> Hi Dariusz,
> thanks for raising that point :-)
>
> With existing OpenID authentication you basically have a generated HTTP password stored in Gerrit and with other OAuth providers you have a similar approach (OAuth persistent code).

Then one need to setup ~/.netrc with generated password and (also)
"generated" user name nice double '@' sings would confuse http (I
believe). Of course this is doable (we all done that for gerrt-review)
but it isn't the best user experience one could get.

> With regards to Git/SSH, things are different as you are not authenticated against your Realm but against a published SSH public key. The point would then be different and would relate to Group Backend implementation and associated authorisation.

I believe SSH should be taken into account from the very beginning. If
it isn't we may end up rewriting everything from scratch "just" to add
SSH support later on.

[Luca Milanesio]

> On 25 Feb 2015, at 08:42, Dariusz Luksza <dariusz...@gmail.com> wrote:
>
> On Wed, Feb 25, 2015 at 9:34 AM, Luca Milanesio
> <luca.mi...@gmail.com> wrote:
>> Hi Dariusz,
>> thanks for raising that point :-)
>>
>> With existing OpenID authentication you basically have a generated HTTP password stored in Gerrit and with other OAuth providers you have a similar approach (OAuth persistent code).
>
> Then one need to setup ~/.netrc with generated password and (also)
> "generated" user name nice double '@' sings would confuse http (I
> believe). Of course this is doable (we all done that for gerrt-review)
> but it isn't the best user experience one could get.

Yep, not a nice experience but people lived with it for years using OpenID or LDAP auth (before I introduced the gitBasicAuth flag a few years ago ).

>
>> With regards to Git/SSH, things are different as you are not authenticated against your Realm but against a published SSH public key. The point would then be different and would relate to Group Backend implementation and associated authorisation.
>
> I believe SSH should be taken into account from the very beginning. If
> it isn't we may end up rewriting everything from scratch "just" to add
> SSH support later on.

OAuth doesn't support SSH public key authentication at all ... and Group Backends are a different topic.
We can discuss the options here, but there is nothing we can do in DavidO change for address Group Backends solution.

Additionally OAuth does not specify anything related to the authorisation policies which remains a provider-specific implementation.
In a nutshell, for GitHub you'll need a GitHub GroupBackend (which already exists and is included in the github-plugin) to expose GitHub Organisation and Teams as Gerrit Groups.

On GerritHub.io the GitHub group backends work nicely right now :-)

For other OAuth providers (BitBucker, Google, ...) it *has to be* done ad-hoc as there are no OAuth standards around that.

Luca.

[Dariusz Luksza]

On Wed, Feb 25, 2015 at 9:49 AM, Luca Milanesio

<luca.mi...@gmail.com> wrote:
>
>> On 25 Feb 2015, at 08:42, Dariusz Luksza <dariusz...@gmail.com> wrote:
>>
>> On Wed, Feb 25, 2015 at 9:34 AM, Luca Milanesio
>> <luca.mi...@gmail.com> wrote:
>>> Hi Dariusz,
>>> thanks for raising that point :-)
>>>
>>> With existing OpenID authentication you basically have a generated HTTP password stored in Gerrit and with other OAuth providers you have a similar approach (OAuth persistent code).
>>
>> Then one need to setup ~/.netrc with generated password and (also)
>> "generated" user name nice double '@' sings would confuse http (I
>> believe). Of course this is doable (we all done that for gerrt-review)
>> but it isn't the best user experience one could get.
>
> Yep, not a nice experience but people lived with it for years using OpenID or LDAP auth (before I introduced the gitBasicAuth flag a few years ago ).
>
>>
>>> With regards to Git/SSH, things are different as you are not authenticated against your Realm but against a published SSH public key. The point would then be different and would relate to Group Backend implementation and associated authorisation.
>>
>> I believe SSH should be taken into account from the very beginning. If
>> it isn't we may end up rewriting everything from scratch "just" to add
>> SSH support later on.
>
> OAuth doesn't support SSH public key authentication at all ... and Group Backends are a different topic.
> We can discuss the options here, but there is nothing we can do in DavidO change for address Group Backends solution.

GorupBackend is responsible for authorization, we are now talking
about authentication. I would not include GoupBackend in this
discussion (it is already implemented ;)).

> Additionally OAuth does not specify anything related to the authorisation policies which remains a provider-specific implementation.
> In a nutshell, for GitHub you'll need a GitHub GroupBackend (which already exists and is included in the github-plugin) to expose GitHub Organisation and Teams as Gerrit Groups.

Not all OAuth providers will give you authorization part (for usage in
GroupBackend) also not all will provide you SSH public key. GitHub
will give you all that, but for others you need to have a way how to
associate your SSH public key with Gerrit account. I can imagine that
one can use his login/account name that comes from OAuth and public
key. If we are lucky this could work out of the box...

But you are right Luca, this is not a time to discuss details. Just
wanted to point this use case out so that it won't be forgotten during
reimplementation ;)

[Luca Milanesio]

Yep, agreed :-)

It will definitely be a point to explore further ... but unfortunately OAuth doesn't help the discussion :-(

[Kelly Campbell]

I don't know that this is strictly an oauth problem, but I've setup a new gerrit instance using the oauth patch and the plugin. I was able to get this to work great, however, I'm not able to access gerrit via ssh key. I saw something in this thread about oauth ssh not being supported, but I assume this is something different than public key ssh into gerrit using the ssh-key on the user account?

The error in sshd_log is "user-not-found"

My ssh key is in the database, and my ssh client is attempting to use that key.

One thing I notice that's different from older gerrit instances I admin is the "username" field is blank in my preferences, and I can't find a way to set that from the UI. I set it via inserting the username: external id in the db, and now ssh works.

Maybe this is something to fix in the ssh-key add instead of in the oauth registration?

-Kelly

[David Ostrovsky]

Am Donnerstag, 5. März 2015 20:12:44 UTC+1 schrieb Kelly Campbell:

I don't know that this is strictly an oauth problem, but I've setup a new gerrit instance using the oauth patch and the plugin. I was able to get this to work great, however, I'm not able to access gerrit via ssh key. I saw something in this thread about oauth ssh not being supported, but I assume this is something different than public key ssh into gerrit using the ssh-key on the user account?

The error in sshd_log is "user-not-found"

My ssh key is in the database, and my ssh client is attempting to use that key.

One thing I notice that's different from older gerrit instances I admin is the "username" field is blank in my preferences, and I can't find a way to set that from the UI. I set it via inserting the username: external id in the db, and now ssh works.

 

Maybe this is something to fix in the ssh-key add instead of in the oauth registration?

I think it's OAuth registration bug. Th issue is with Google OAuth scopes. There are

two different userinfo scopes: email and profile [1].

When email scope is used, correct username is returned "jdoe" (in field name),

but the fullname is missing.

When profile scope is used, then the fullname is returned "John Doe" (in field name),

but the username is missing. Why can't login, like for GitHub [2], always be returned?

I used only "email" scope in the plugin first, but changed it to "email profile" later: [3].

I think to solve SSH access problem, we should try to retrieve uername, also remove

"profile" from the scope. Full name can be always specified from the UI. Another task

is to insert or to link the username record into account_external_ids table during OAuth

registration.

[1] https://developers.google.com/+/api/oauth#login-scopes

[2] https://developer.github.com/v3/users/#get-the-authenticated-user

[3] https://github.com/davido/gerrit-oauth-provider/blob/master/src/main/java/com/googlesource/gerrit/plugins/oauth/GoogleOAuthService.java#L47

[David Ostrovsky]

Am Donnerstag, 5. März 2015 20:12:44 UTC+1 schrieb Kelly Campbell:

I don't know that this is strictly an oauth problem, but I've setup a new gerrit instance using the oauth patch and the plugin. I was able to get this to work great, however, I'm not able to access gerrit via ssh key. I saw something in this thread about oauth ssh not being supported, but I assume this is something different than public key ssh into gerrit using the ssh-key on the user account?

The error in sshd_log is "user-not-found"

My ssh key is in the database, and my ssh client is attempting to use that key.

One thing I notice that's different from older gerrit instances I admin is the "username" field is blank in my preferences, and I can't find a way to set that from the UI. I set it via inserting the username: external id in the db, and now ssh works.

I've extended the extension point and changed the plugin to provide user name.

Registration of new user should work. Username should be honored. Linking of

existing account isn't handled yet.

Can you give it another try? Is SSH access problem is solved for new users?

[Kelly Campbell]

Sorry it took me a while before I had a chance to test this out. I tried it. The user can register a new account logging in via Google, but they still didn't have a "username:" entry in account_external_ids

The Full Name in their settings was also not set.

I should have a bit of time to do more testing/debugging this weekend.

-Kelly

[David Ostrovsky]

Am Freitag, 13. März 2015 21:28:45 UTC+1 schrieb Kelly Campbell:

Sorry it took me a while before I had a chance to test this out. I tried it. The user can register a new account logging in via Google, but they still didn't have a "username:" entry in account_external_ids

I just re-checked it on a fresh site, on 2.10.1 with the latest plugin

version. Works here as expected: username is set during registration.

ACCOUNT_EXTERNAL_IDS has two entries: OpenID Connect user

identity and username.

Can you check if alias is set for the user on the Google account side?

Username is mapped to alias and this is optional attribute.

The Full Name in their settings was also not set.

That's expected. That's how the endpoint works for this scope: [1]. But you

can always set users full name from the UI, so this shouldn't be a problem.

[1] https://github.com/davido/gerrit-oauth-provider/blob/master/src/main/java/com/googlesource/gerrit/plugins/oauth/GoogleOAuthService.java#L90,L93

[David Ostrovsky]

Am Freitag, 13. März 2015 22:27:01 UTC+1 schrieb David Ostrovsky:

Am Freitag, 13. März 2015 21:28:45 UTC+1 schrieb Kelly Campbell:

Sorry it took me a while before I had a chance to test this out. I tried it. The user can register a new account logging in via Google, but they still didn't have a "username:" entry in account_external_ids

I just re-checked it on a fresh site, on 2.10.1 with the latest plugin

version. Works here as expected: username is set during registration.

ACCOUNT_EXTERNAL_IDS has two entries: OpenID Connect user

identity and username.

Can you check if alias is set for the user on the Google account side?

Username is mapped to alias and this is optional attribute.

On second though i think it was a mistake to assume that username can

be always induced for every OAuth provider. The plugin was derived from

GitHub OAuth implementation, though.

I think that the extension point cannot make this assumption, that username,

full name and all emails are always exposed by all OAuth providers. Instead,

we should allow to edit them, like it is the case for OpenID auth scheme.

I am working on the extension here, both in Gerrit core and in plugin: not to try

to induce username, but expose the fullname instead.

[David Ostrovsky]

Am Mittwoch, 25. Februar 2015 08:49:25 UTC+1 schrieb David Ostrovsky:

After abandoning the approach to support one single OAuth authentication

scheme in Gerrit core, revamped attempt was started to support multiple

OAuth providers.

The idea is to restrict the core to only expose OAuth extension point and

use Gerrit plugin concept to provide support for multiple OAuth providers,

like it was done with Gerrit scripting plugin providers.

This change exposes such extension point [1] and offer provider selection

dilaog in case multiple OAuth provider plugins were deployed: [2].

Google OAuth2 provider plugin is available [3] that depends on this extension

point: [2]. Further OAuth provider plugins will follow.

TODO:

* support anonymous browsing, with redirect to login dialog when required

Done.

 

* support linking different OAuth identities to existing account

Partially done: Google OAuth accounts can be linked to OpenID accounts.

Pre built version of the plugin: [1] is available on GH: [2]. I also created

bundled Gerrit release: [3]. Bundled version simplifies plugin installation

and configuration: [4].

[1] https://github.com/davido/gerrit-oauth-provider

[2] https://github.com/davido/gerrit-oauth-provider/releases/tag/v0.1

[3] https://github.com/davido/gerrit-oauth-provider/releases/download/v0.1/gerrit-2.10.1-4-a83387b.war

[4] http://paste.openstack.org/show/195219/

[Luca Milanesio]

Hi David,

I have to say ... amazing job :-) well done !

One *very important* think we are still missing is Shawn's feedback though.

April is approaching fast and we cannot afford restarting again as we did for the first attempt.

Luca.

[Luca Milanesio]

Seems that has been merged :-O well done again then ;-)

Luca.

[David Ostrovsky]

Am Montag, 23. März 2015 09:00:03 UTC+1 schrieb lucamilanesio:

Hi David,

I have to say ... amazing job :-) well done !

Thanks!

 

One *very important* think we are still missing is Shawn's feedback though.

Actually we do have his feedback on this topic: [1]. Let me quote it for you:

" [...] I don't have the time, will, or energy to make the changes and keep chasing

whatever new fancy "standard" Google has decided to demand on application

developers in order to use Google Accounts for authentication to their website.

If someone else does the work, OK. But it ain't going to be me. [...] "

IOW this time is the Gerrit community that must provide a solution to this problem.

[1] https://groups.google.com/d/topic/repo-discuss/nrtxry9SNLg/discussion

[Luca Milanesio]

I think that the key was really introducing everything external through plugin, so that for Gerrit is a simple extension point with no extra deps.

Again … plugin approach is the winner :-)

One question: where to attach the github plugin now?

Option a) extend the Gerrit OAuth provider which includes GitHub auth as well  [1]

Option b) implement a brand new OAuth provider and provide yet another implementation of OAuth with GitHub 

What do you (we as Gerrit community) think / suggest ?

Luca.

[1] https://github.com/davido/gerrit-oauth-provider

[David Ostrovsky]

Am Montag, 23. März 2015 11:18:41 UTC+1 schrieb lucamilanesio:

I think that the key was really introducing everything external through plugin, so that for Gerrit is a simple extension point with no extra deps.

Again … plugin approach is the winner :-)

Yepp. And we have learned this lesson from your attempt to integrate

GitHub OAuth in Gerrit core. So your 57 iterations weren't in vain...

One question: where to attach the github plugin now?

Option a) extend the Gerrit OAuth provider which includes GitHub auth as well  [1]

Gerrit OAuth provider [1] has already support for GitHub auth, even with documentation: [2].

[1] https://github.com/davido/gerrit-oauth-provider

[2] https://github.com/davido/gerrit-oauth-provider/wiki/Getting-Started#obtaining-provider-authorizations

[Luca Milanesio]

Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?

- Scopes configuration

- Profile import

- Repositories import and replication

- Pull requests imported as Change + PatchSets

- Group backend for GitHub organisation and teams

- Template engine with configurable wizard post-login

… and more stuff is planned.

IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?

But then how to use the gerrit-oauth-provider and link to it from the github plugin?

Luca.

[David Ostrovsky]

Am Montag, 23. März 2015 11:42:28 UTC+1 schrieb lucamilanesio:

Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?

Nope.

 

- Scopes configuration

- Profile import

- Repositories import and replication

- Pull requests imported as Change + PatchSets

- Group backend for GitHub organisation and teams

- Template engine with configurable wizard post-login

… and more stuff is planned.

IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?

Yes. That should stay in GitHub plugin.

 

But then how to use the gerrit-oauth-provider and link to it from the github plugin?

This is a good question. When we don't find an easy way to re-user the gerrit-oauth-provider

in GitHub plugin, we could still have two different implementation: OAuth only (like old OpenID

stuff) and full fledged GH integration provided by GitHub plugin that you've mentioned above.

[Luca Milanesio]

On 23 Mar 2015, at 10:49, David Ostrovsky <david.o...@gmail.com> wrote:

Am Montag, 23. März 2015 11:42:28 UTC+1 schrieb lucamilanesio:

Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?

Nope.

Same here :-)

 

- Scopes configuration

- Profile import

- Repositories import and replication

- Pull requests imported as Change + PatchSets

- Group backend for GitHub organisation and teams

- Template engine with configurable wizard post-login

… and more stuff is planned.

IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?

Yes. That should stay in GitHub plugin.

Yep.

 

But then how to use the gerrit-oauth-provider and link to it from the github plugin?

This is a good question. When we don't find an easy way to re-user the gerrit-oauth-provider

in GitHub plugin, we could still have two different implementation: OAuth only (like old OpenID

stuff) and full fledged GH integration provided by GitHub plugin that you've mentioned above.

That was my first initial feeling … even if I wouldn’t like it that much :-(

Is there any way to do something similar to the its-base / its-jira plugins ? That including the gerrit-oauth-provider at compile time to github to effectively reuse the OAuth implementation and avoid duplication?

Best would be plugin-to-plugin dependency loading … but I think we’ve already discussed that topic isn’t it ?

Luca.

[David Ostrovsky]

Am Montag, 23. März 2015 11:54:49 UTC+1 schrieb lucamilanesio:

On 23 Mar 2015, at 10:49, David Ostrovsky <david.o...@gmail.com> wrote:

Am Montag, 23. März 2015 11:42:28 UTC+1 schrieb lucamilanesio:

Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?

Nope.

Same here :-)

 

- Scopes configuration

- Profile import

- Repositories import and replication

- Pull requests imported as Change + PatchSets

- Group backend for GitHub organisation and teams

- Template engine with configurable wizard post-login

… and more stuff is planned.

IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?

Yes. That should stay in GitHub plugin.

Yep.

 

But then how to use the gerrit-oauth-provider and link to it from the github plugin?

This is a good question. When we don't find an easy way to re-user the gerrit-oauth-provider

in GitHub plugin, we could still have two different implementation: OAuth only (like old OpenID

stuff) and full fledged GH integration provided by GitHub plugin that you've mentioned above.

That was my first initial feeling … even if I wouldn’t like it that much :-(

Is there any way to do something similar to the its-base / its-jira plugins ? That including the gerrit-oauth-provider at compile time to github to effectively reuse the OAuth implementation and avoid duplication?

Best would be plugin-to-plugin dependency loading …

Yepp. Something like that.

 

but I think we’ve already discussed that topic isn’t it ?

Discussed? Are you joking? ;-)

I've spent quite some time to implement cross-plugin-dependency feature: [1],

and this series was in very good shape (like all my changes ;-), but ... it wasn't

merged in the end.

[1] https://gerrit-review.googlesource.com/#/q/project:gerrit+branch:master+topic:plugin-dependencies

[Luca Milanesio]

Yes, I am :-) … I remember the story :-)

I've spent quite some time to implement cross-plugin-dependency feature: [1],

and this series was in very good shape (like all my changes ;-), but ... it wasn't

merged in the end.

[1] https://gerrit-review.googlesource.com/#/q/project:gerrit+branch:master+topic:plugin-dependencies

Yep, is it a good moment to revive the change again?

[Eberhard]

On Monday, March 23, 2015 at 8:44:03 AM UTC+1, David Ostrovsky wrote:

 

* support linking different OAuth identities to existing account

Partially done: Google OAuth accounts can be linked to OpenID accounts.

How do you use that? I tried and installed the bundled Gerrit release and configured the plugin. I can login through Google OAuth, but it creates a new user instead of linking it with the existing Google OpenID one. What does it use to match the accounts? The email address? Or the full name?

Thanks,
    Eberhard

[David Ostrovsky]

Am Montag, 23. März 2015 15:26:28 UTC+1 schrieb Eberhard:

On Monday, March 23, 2015 at 8:44:03 AM UTC+1, David Ostrovsky wrote:

 

* support linking different OAuth identities to existing account

Partially done: Google OAuth accounts can be linked to OpenID accounts.

How do you use that?

I explained how it works and how to troubleshoot it in this issue: [1].
Under certain circumstances Google OAuth JWT token response
would include OpenID identity for the user. This OpenID identity is
used for linking.

[1] https://github.com/davido/gerrit-oauth-provider/issues/2

[lucamilanesio]

Hi David,

I've setup a build job on ci.gerritforge.com for the gerrit-oauth-provider ... but it failed on master :-(

See the output at [1].

The problem seems to be the incompatibility with Gerrit master: is the plugin master version meant to compile against Gerrit 2.10?

What are the branches for Gerrit 2.11 and master?

Thanks in advance for your help in getting the ci sorted out :-)

Luca.

[1] https://ci.gerritforge.com/job/Plugin_gerrit-oauth-provider_master/1/console

[lucamilanesio]

I have posted a change to GitHub-Plugin to implement the new OAuthServiceProvider interface (see [1]).

There are features missing anyway in the OAuthServiceProvider:

- storage of additional external-id (OAuth token) to be used later on for GroupBackend lookup (inside the HTTP auth but not in OAUTH)

- change of scope during a Gerrit session (imagine that I need extra permissions when I navigate the GitHub repos or pull requests)

- choice of the scope at login time

- alternate URL for first-time user registration (for user profile set-up, keys)

- alternate URL for logout (for GitHub logout)

- disabling user profile changes from Gerrit (as you do them from GitHub)

All those features were available when using an HTTP-style authentication and thus I've left at the moment the option to still use the GitHub plugin with HTTP auth.

It would be nice to extend the OAuth authentication (through further extension points) to allow the provider to implement them ... but that's another iteration I guess ;-)

P.S. For the time being the change is on master as IMHO on 2.10 / 2.11 is still safer to use the well consolidated HTTP auth. 

Luca.

[lucamilanesio]

[1] https://gerrit-review.googlesource.com/#/c/66621/

[Rangaraj R]

Hi David, Luca,

Thanks for the patch builds.

I am able to upgrade gerrit with Gerrit OAUTH Provider plugin and it is working fine.

I have trouble in viewing dependencies(Depends On and Needed By) for each changes.

Please let me know if  config change needed.

Thanks,

Rangaraj

[David Ostrovsky]

Am Mittwoch, 25. Februar 2015 08:49:25 UTC+1 schrieb David Ostrovsky:

After abandoning the approach to support one single OAuth authentication

scheme in Gerrit core, revamped attempt was started to support multiple

OAuth providers.

The idea is to restrict the core to only expose OAuth extension point and

use Gerrit plugin concept to provide support for multiple OAuth providers,

like it was done with Gerrit scripting plugin providers.

[...]

 

TODO:

* support anonymous browsing, with redirect to login dialog when required

 

Done.

* support linking different OAuth identities to existing account

Done.

 

Are we done? For new sites yes, for existing sites, that depend on OpenID, not.

Problem:

Unfortunately this is still not sufficient migration path for Gerrit installations that

are using OpenID atm. What is needed is hybrid OpenID/OAuth authentication

scheme. This authentication option is indispensable for all Gerrit installations

in the wild that currently depend on OpenID, and with Google's end of life of

OpenID are screwed up, as only part of their user base is using deprecated

OpenID provider, while a substantial part of their user base is still using sane

OpenID providers.

Solution:

Offer aforementioned hybrid OpenID/OAuth authentication option and support

linking user identities across different authentication scheme (OpenID -> Oauth).

 

Done.

Ideally, this feature should be available (and released) before April 20, 2015.

2.10.3.1 and 2.11 releases have everything needed for Hybrid OpenID+OAuth

to work properly. Well, almost. Linking of identities across protocol boundaries

from the UI is implemented: [1] but wasn't merged yet.

There is also FAQ available on the GH plugin page: [2].

[1] https://gerrit-review.googlesource.com/67281

[2] https://github.com/davido/gerrit-oauth-provider/wiki/FAQ