Atlassian Crowd auth support for gerrit

[Eric Anderson]

Hey Everyone,

I just finished implementing a new auth type for gerrit to let you use Atlassian Crowd instead of LDAP. I would appreciate any feedback and I am sure Shawn would appreciate someone else looking at this and trying it before he +2's the commit :)

The current change can be found: https://review.source.android.com/24928

Thanks,
Eric

[Luca Milanesio]

Hi Eric,

would it be better, instead of keep on adding others 'switch/case' in AuthType.java ... to introduce the concept of "pluggable auth" and auth provider plug-in ?
This would allow a simpler extensibility to other ALMs, such as CollabNet, Rally, MSVTS etc.

@Shawn: what do you think ?

Luca.

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

[Eric Anderson]

I would tend to agree with you if someone had a 3rd username/password implementation they were dedicated to writing. Three times means you need a framework, two doesn't quite make it worth it.

$0.02
-EA

[Luca Milanesio]

We are about to write the CollabNet user/password implementation (1=LDAP, 2=SITEMINDER, 3=CROWD, 4=COLLABNET) ... I think it would be worth avoiding to increase the if/then/else ratio ;-)
Moreover the AuthType.java is not the only part where you need to add extra 'case' in the big 'switch'.

£0.02

Luca

[Eric Anderson]

So what are you thinking? Is this an extensibility point or just better code factoring for multiple auth types?

I'd favor better factoring so that we can keep Gerrit install/setup as painless as possible.

-EA

[Luca Milanesio]

Hi Eric,

much more an extensibility point, something like:

- AuthType => External
- External plug-in => Jar file

... and Jar file gets loaded dynamically and stored in the GERRIT_SITE/bin.

External plug-in will provide its initialisation steps as well:
- auth url
- protocol
- any other relevant info

Another one that will be very popular would be MQC (probably we could do it very soon), Assembla or others.

What do you think ?

Luca.

[Eric Anderson]

Reading through the code, this looks feasible. We could load jars in /lib/ since gerrit lays that structure down but it doesn't seem to be used?

I would continue to support:

[auth]
type = CROWD
crowdUser = BLAH
crowdPassword = BLAH
crowdUrl = BLAH

I would think an easy way to do this would be to put files in the META-INF like so:

/META-INF/gerritplugin/auth/CROWD.conf

type = usernamepassword
module = com.path.to.my.module

This would also let the LDAP and friends be implemented as plugins but also bundled with what Gerrit ships. It would also allow us to bundle various auth plugins if we decide thats desirable.

Thoughts?

[Luca Milanesio]

Sounds good to me.

@Shawn: what do you think ? I guess this would be a step forward to integrate Gerrit with other enterprise ALMs :-)

Luca.

[Eric Anderson]

I had a patch pre-plugins. It wouldn't be too hard to adapt. Its still in the reviews somewhere.

On Jul 3, 2012, at 7:38 AM, Mario Tokarz wrote:

Hi all,

On Saturday, July 30, 2011 12:24:17 AM UTC+2, lucamilanesio wrote:

Sounds good to me.

@Shawn: what do you think ? I guess this would be a step forward to integrate Gerrit with other enterprise ALMs :-)

Luca.

I couldn't find any references to CROWD in the current source tree (master). Just as not to miss anything: was there any movement on this issue from this point on? To me this still seems like an interesting feature to have, so I would like to look a bit into it.

Thanks,
Mario 

[Luca Milanesio]

Hi Mario,

Gerrit allows to trust HTTP authentication and use an header to get the current user.

Regarding the groups support, the master includes the ability to integrate 3rd party Group providers: Crowd can be now easily integrated with this.

On the Jira integration, I am working on a hooks-jira plug-ins and commit-validation plug-in.

Those three points should cover then:

a) SSO

b) Groups management

c) Issue tracker association and commit validation

Would you need more for integrating with Atlassian ? :-)

Luca.

On 3 Jul 2012, at 12:38, Mario Tokarz wrote:

Hi all,

On Saturday, July 30, 2011 12:24:17 AM UTC+2, lucamilanesio wrote:

Sounds good to me.

@Shawn: what do you think ? I guess this would be a step forward to integrate Gerrit with other enterprise ALMs :-)

Luca.

I couldn't find any references to CROWD in the current source tree (master). Just as not to miss anything: was there any movement on this issue from this point on? To me this still seems like an interesting feature to have, so I would like to look a bit into it.

Thanks,
Mario 

[Eric Anderson]

Luca, how will the commit validation plugin work?

[Luca Milanesio]

Hi Eric,

basically there will be a new extension point in Gerrit 2.5 that will allow you to "participate" in the commit validation.

My goal is to allow to "block commits" if they are not compliant with some Jira issues associations.

(i.e. mentioning a valid opened Jira issue)

P.S. This will be a plug-in on Gerrit 2.5.

Let me know about your use-cases so I can help out :-)

Luca.

[Mario Tokarz]

Ciao Luca,

sorry, a bit of a delay due to vacation.

On Tuesday, July 3, 2012 4:06:33 PM UTC+2, lucamilanesio wrote:

Hi Mario,

Gerrit allows to trust HTTP authentication and use an header to get the current user.

Regarding the groups support, the master includes the ability to integrate 3rd party Group providers: Crowd can be now easily integrated with this.

On the Jira integration, I am working on a hooks-jira plug-ins and commit-validation plug-in.

Those three points should cover then:

a) SSO

b) Groups management

c) Issue tracker association and commit validation

Thanks for the detailled answer. Up to now I'm looking into different possible solutions to integrate group mgmt system which has been a question that came up quite frequently.

 

Would you need more for integrating with Atlassian ? :-)

So, I don't know yet - I'll look a bit more into the Plug-In API - would you guys be interested in more integration with Atlassian as well? 

 

Best,

Mario

[Luca Milanesio]

Hi Mario,

On 10 Jul 2012, at 08:22, Mario Tokarz wrote:

 

Would you need more for integrating with Atlassian ? :-)

So, I don't know yet - I'll look a bit more into the Plug-In API - would you guys be interested in more integration with Atlassian as well? 

the "hooks-jira" plug-in is very much an exercise to understand if we can plug an external system to Gerrit and see if the current listener / extensions points would suffice.

Feel free to submit your needs so we can see what's missing :-)

Luca.

[Ashwin Ramesh]

Hello,

I was just going through different topics in Gerrit discussion group and encountered this.
Has there been any latest patch on Gerrit with respect to Atlassian Crowd?

Also, I was not able to access the link. https://review.source.android.com/24928
Has the document been removed or don't I have the permission?

Thanks,
Ashwin

[Luca Milanesio]

We discussed the topic  and decided to introduce the plugins concept in Gerrit.

There is an "auth backend" plugin extension ready and under review: once that would be merged then Crowd (and any other commercial product integration) can be provided as plugin, without adding extra "switch/case" into the Gerrit code-base (as the proposed change was doing)

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/groups/opt_out.
 
 

[Ashwin Ramesh]

Hi Luca,

Thanks for the reply.
1. Do you know when would the "auth backend" plugin extension be merged?
2. Is it already in the 2.6 release or will it be ready for the 2.7?
3. Also is the crowd patch also provided as a plugin along with the release?

Thanks,
Ashwin

[Andrew Diller]

The current version of Crowd comes with an OpenID provider. We are using that to allow Gerrit to auth to 2 LDAP backends- one direct to LDAP server, the other to a MicrosoftActiveDirectory via Crowd. It works great.

So it looks like this:

gerrit --> OpenID -> Crowd -> LDAP -> ActiveDirectory

        --> OpenID -> Crowd -> LDAP -> OpenLDAP

again, this works today very nicely.

[Ashwin Ramesh]

Hi Andrew,

Does the current version of Crowd, support the groups or is it for authentication only?

----Ashwin----

[Andrew Diller]

It is just for auth, since the LDAP servers to us are ReadOnly, we cannot control the groups. But I have not investigated this deeply.

In our case this is just what we want- usually our LDAP servers are a mess, it's easier for us to control groups on gerrit itself.

-andy

[Philipp Altmann]

Hi Luca,

there are any plans when the auth backend plugin will be relased? 

I don't see anything in the projects list. The only project is the Google Apps Group plugin but this is an empty project. 

https://gerrit.googlesource.com/plugins%2Fgoogle-apps-group

There are plans to extract stuff like siteminder to a plugin? 

Cheers, 

Philipp 

[Luca Milanesio]

Hi Philipp,

the auth backend patch is still under review :-( ... I agree we should should push for merging it !

A first merge was tried a while ago but broke some functionality.

There is however another possibility now, using the ServletFilter + HTTP Auth as I did in the GitHub plugin, integrating SSO and authentication through GitHub OAuth scheme.

It seems that Jira 6.x supports OAuth, so it should not be very different from the current implementation with GitHub.

The values are:

- completely transparent to Gerrit

- allows auto-provisioning of e-mail, keys and other info from your profile

Luca.

[Luca Milanesio]

It seems from this picture that Crowd supports OpenID: it should then be available out-of-the-fox with Gerrit.

https://www.atlassian.com/en/software/crowd/overview/overviewHero/imageBinary/crowd_hero_new.png

Have you tried to use the OpenID interface with Crowd ?

Luca.

[Philipp Altmann]

Hi Luca, 

auth via Apache + Crowd works already fine. A question that came up quite frequently is that Gerrit uses the groups vom Crowd so no duplicate group mgmt is needed. 

Currently we do unidirectional manual sync between this 2 systems. At 2.5.1 there was no REST API available :-)

It would be nice to use Crowd groups like in LDAP.  

Philipp

[Luca Milanesio]

Ah, you mean then a Group Backend integration rather than auth.

That should not be difficult and it could be included in the Jira plugin.

When using Jira, you typically have the groups already defined and accessible from the Jira API.

Would that work for you ?

Luca.

[Philipp Altmann]

Hmm. The Jira Plugin could be extended but for the Crowd use case a new plugin would be better because it's a different tool.

The problem is if you have a Crowd instance you don't use the internal Jira Group Management because you already have the user management in Crowd. 

The first step could be to develop a plugins/gmgmt-base plugin. This could use the REST API to create User / Groups etc. On the other side should this a Gerrit Plugin or more a Crowd Plugin which can pushes changes to Gerrit.  

Another question from me is, as already mentioned, if there are plans to extract SSO thins from core to a plugin like Siteminder etc. 

Philipp 

[Luca Milanesio]

In this case is really a completely different plugin: just a "Crowd Group Backend" plugin.

I thought that Crowd was "transparent" from a Jira API perspective ... but you're telling me that once you use Crowd Groups you don't use the Jira ones ;-(

Do you want to start writing the plugin ?

You could use "singleusergroup" as an example of it.

Luca.

[Mohan .S]

Hi Team,

 

This is regarding apache2, Crowd authentication with Directory based LDAP issue with Git/Gerrit.

 

My Environment details:

Operating system: Ubuntu 12.4 LTS – 64 bit.

Apache2 Version

Server version: Apache/2.2.22 (Ubuntu)

Server built:   Mar  5 2015 18:10:14

Crowd Version - Atlassian Crowd Version: 2.8.2

 

Problem description:-

 

I have configured Crowd authentication with Delegated directory type Microsoft Active Directory with our LDAP settings and provided necessary permissions to crowd-openid-server settings and to our git/gerrit server.

 

Currently my (gerrit.config) file has below settings to access our git/gerrit portal.

 

[auth]

  type = OPENID_SSO

  openIdSsoUrl = http://100.101.102.103:8095/openidserver/

 logoutUrl = http:// 100.101.102.103:8095/gerrit_logout.html

 

But when tried access my gerrit portal, front end shows sign in button once I clicked that the authentication not forwarding to crowd page to enter my login-id and password. It remains on local host itself(means remains in gerrit portal itself).

 

Note: we have two servers: one for Git/Gerrit & another one for Crowd.

 

So kindly advise me to fix the same.

 

Thanks,

Mohan

[Luca Milanesio]

Hi Mohan,

see my feedback below.

On 28 May 2015, at 11:54, Mohan .S <moha...@gmail.com> wrote:

Hi Team,

 

This is regarding apache2, Crowd authentication with Directory based LDAP issue with Git/Gerrit.

Are you referring then of using Gerrit with LDAP authentication where Crowd is the LDAP Server?

https://marketplace.atlassian.com/plugins/net.wimpi.crowd.ldap.crowd-ldap-server

 

My Environment details:

Operating system: Ubuntu 12.4 LTS – 64 bit.

Apache2 Version

Server version: Apache/2.2.22 (Ubuntu)

Server built:   Mar  5 2015 18:10:14

Crowd Version - Atlassian Crowd Version: 2.8.2

 

Problem description:-

 

I have configured Crowd authentication with Delegated directory type Microsoft Active Directory with our LDAP settings and provided necessary permissions to crowd-openid-server settings and to our git/gerrit server.

Hold on … you are using Active Directory LDAP then: why are you authenticating against Atlassian Crowd then?

 

Currently my (gerrit.config) file has below settings to access our git/gerrit portal.

 

[auth]

  type = OPENID_SSO

  openIdSsoUrl = http://100.101.102.103:8095/openidserver/

 logoutUrl = http:// 100.101.102.103:8095/gerrit_logout.html

Is Crowd an OpenID provider? What is its URL? Where do you typically sign-in in Crowd? What do you put in the browser URL?

 

But when tried access my gerrit portal, front end shows sign in button once I clicked that the authentication not forwarding to crowd page to enter my login-id and password. It remains on local host itself(means remains in gerrit portal itself).

Possibly the openIdSsoUrl is wrong then :-)

But again … why are you making it so complicated? Why don’t you just authenticate against LDAP?

Luca.

[Mohan .S]

Hi Luca,

I am trying to configure "Crowd openidserver for authentication"

-Mohan

[Mohan .S]

Hi Team,

Gerrit Log shows following msg,

[2015-05-29 12:29:41,679] INFO  org.eclipse.jetty.server.ServerConnector : Started ServerConnector@53e74514{HTTP/1.1}{0.0.0.0:8080}
[2015-05-29 12:29:41,680] INFO  org.eclipse.jetty.server.Server : Started @8987ms
[2015-05-29 12:29:41,682] INFO  com.google.gerrit.pgm.Daemon : Gerrit Code Review 2.10.2 ready
[2015-05-29 12:30:01,605] ERROR com.google.gerrit.httpd.auth.openid.OpenIdServiceImpl : Cannot discover OpenID http://100.101.102.103:8095/openidserver/op
org.openid4java.discovery.yadis.YadisException: 0x706: GET failed on http://100.101.102.103:8095/openidserver/op : 404
        at org.openid4java.discovery.yadis.YadisResolver.retrieveXrdsLocation(YadisResolver.java:411)
        at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:252)
        at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:232)
        at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:166)
        at org.openid4java.discovery.Discovery.discover(Discovery.java:147)
        at org.openid4java.discovery.Discovery.discover(Discovery.java:129)
        at org.openid4java.consumer.ConsumerManager.discover(ConsumerManager.java:538)
        at com.google.gerrit.httpd.auth.openid.OpenIdServiceImpl.init(OpenIdServiceImpl.java:525)
        at com.google.gerrit.httpd.auth.openid.OpenIdServiceImpl.discover(OpenIdServiceImpl.java:152)
        at com.google.gerrit.httpd.auth.openid.LoginForm.discover(LoginForm.java:165)
        at com.google.gerrit.httpd.auth.openid.LoginForm.doGet(LoginForm.java:114)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
        at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:279)
        at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:269)
        at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:180)
        at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
        at com.google.gwtexpui.server.CacheControlFilter.doFilter(CacheControlFilter.java:70)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
        at com.google.gerrit.httpd.RunAsFilter.doFilter(RunAsFilter.java:113)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:64)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:57)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
        at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:75)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
        at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:119)
        at com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:133)
        at com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:130)
        at com.google.inject.servlet.GuiceFilter$Context.call(GuiceFilter.java:203)
        at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:130)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1636)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:219)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1111)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
        at org.eclipse.jetty.server.Server.handle(Server.java:461)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
        at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
        at java.lang.Thread.run(Thread.java:745)

Thanks,
Mohan

[David Pursehouse]

This looks like the root cause:

GET failed on http://100.101.102.103:8095/openidserver/op : 404

--
--
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.

[Mohan .S]

Hi David,

Yes i have tried like below also, Means my gerrit.config,

[auth]
        type = OPENID_SSO
        openIdSsoUrl = http://100.101.102.103:8095/openidserver/

After the below change,

Once i click the "Signin" button it shows below error.

Provider is not supported, or was incorrectly entered.

It need to work like below.

gerrit--> crowd-openid-server--> LDAP--> ActiveDirectory

-Mohan

[Luca Milanesio]

Hi Mohan,

I think the issue is more with Altassian Crowd OpenID server than Gerrit :-(

Have you tried asking on the Atlassian mailing list? Or StackOverflow? Or asking Atlassian Support?

Can you test first the Crowd OpenID standalone and validate that works fine?

Luca.

[Ganesh Babu]

Hi Al

my keyclock url - https://192.168.2.1:8443 my gerrit apps - http://192.168.1.1:7070 so i used valid urls in keycloack client as - http://192.168.1.1:7070

my gerrit.config

[plugin "gerrit-oauth-provider-keycloak-oauth"]
        root-url = https://192.168.2.1:8443
        realm = master
        client-id = gerrit

But i am getting error as in UI when gerrit redirect to keycloack We're sorry Invalid parameter: redirect_uri Could you please help me how to resolve it ...

Regards

Ganeshbabu N

[David Ostrovsky]

On Friday, January 25, 2019 at 8:22:18 AM UTC+1, Ganesh Babu wrote:

Hi Al

my keyclock url - https://192.168.2.1:8443 my gerrit apps - http://192.168.1.1:7070 so i used valid urls in keycloack client as - http://192.168.1.1:7070

my gerrit.config

[plugin "gerrit-oauth-provider-keycloak-oauth"]
        root-url = https://192.168.2.1:8443
        realm = master
        client-id = gerrit

But i am getting error as in UI when gerrit redirect to keycloack We're sorry Invalid parameter: redirect_uri Could you please help me how to resolve it ...

Please, avoid spamming old issues/threads with unrelated questions.

Open a new thread or use the dedicated issue on the issue tracker

(plugin or gerrit core). None of the issues/threads is related to KeyCloak

OAuth provider.

You have already commented on this issue: [1] in gerrit-oauth-provider

plugin, and I answered your question in a new issue: [2].

Your redirect_uri configured on KeyCloak side is wrong. See plugin's wiki

how to do it correctly for other OAuth providers and do it similarly for

KeyCloak.

* [1] https://github.com/davido/gerrit-oauth-provider/issues/109#issuecomment-457174763

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

* [3] https://github.com/davido/gerrit-oauth-provider/wiki/Getting-Started