See http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains?pli=1

Relevant thread in the users list: http://groups.google.com/group/jenkinsci-users/browse_frm/thread/8786c1f74db8200/9c1ec47a775265d5?lnk=gst&q=openid

Hi guys, how does it look with this one? Using Google Apps for Hudson authentication would make a pretty nice feature. Keep up the great effort!

Is this ticket still relevant?

We have used the OpenID plugin with our Google Apps account the last couple of weeks without problems.

I'm with @Kasper Garnæs
My jenkins works fine with my google apps domain.
My only open question is how to configure it such that only users of my domain have access.

Yes, it does work (I think Google changed something in the last 8 months). However, like Kevin Behrens said, it only works automatically if you use the generic Google account URL.

If you use the URLs for your specific domain, OpenID generally expects to be able to get the xrds file from your domain, like example.com. Google does host a version of that file for you, but the discovery mechanism is tweaked to allow for it, so you either have to host it yourself or modify the discovery to read the file from the well-known URL pattern on google.

This is mostly from memory so hopefully I got it right.

I found that this ALMOST works. According to this spec: https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery

I can use this endpoint URL (for my domain) in the plugin to get the process started correctly:
https://www.google.com/accounts/o8/site-xrds?hd=example.com

After I validate the login with Google, according to the spec above, the user OpenID file is by default found here:
http://example.com/openid?id=108441225163454056756

But google actually hosts that for you, with this URL template, which is defined in the site XRDS doc.
https://www.google.com/accounts/o8/user-xrds?uri=

So the plugin fails because it doesn't apply that template and instead tires to retrieve the User XRDS doc from example.com.

At least, I think that's what is happening. I am going to try doing a URL rewrite on our web server as a workaround, but hopefully the author can take a look and see if perhaps there is a straightforward fix?

Here's an Apache mod_rewrite + mod_proxy rewrite rule that works for me:

RewriteRule ^/openid$ http://www.google.com/accounts/o8/user-xrds?uri=http://example.com/openid?%

[P,L]

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/plugins/openid/GoogleAppSsoSecurityRealm.java
http://jenkins-ci.org/commit/openid-plugin/c2f725f9dd25462edf95a5e3a59759538ab23136
Log:
[FIXED JENKINS-9216]

Reworked the change based on the comment in the ticket.
This approach does not skip any checks, so it doesn't compromise on
security.

Compare: https://github.com/jenkinsci/openid-plugin/compare/51272cc7dd48...c2f725f9dd25