I recently had to undertake some work to enable users to seamlessly authenticate to Google Apps using an identity stored in a custom Secure Token Service such as the excellent IdentityServer open source STS by Dominick Baier. The work involved is mostly configuration in Google Apps and ADFS but there are quite a number of steps and as it was non-trivial I thought I’d document it here for reference. Note that Google Apps uses SAML 2.0 tokens and because ADFS is brokering the authentication, you shouldn’t have any problems with compatibility as ADFS 2.0 can issue SAML 2.0 tokens.
Here’s a quick architecture diagram:
Key:
Green arrows = user request flow
Blue arrows = service response flow
Overview
For those of you impatient, here’s a quick overview of the steps required:
- Enable SSO in Google Apps
- Enter correct ADFS urls into Google Apps
- Upload ADFS Token Signing Certificate so Google Apps can verify the SAML tokens
- Add Google Apps as a Relying Party in ADFS
- Test
I will now walk through each stage in detail, for those who like the details.
Enable SSO in Google Apps
The first stage is to enable Single Sign-on in Google Apps. Log in to your administration console at /">http://www.google.com/a/<your-domain>/. Click on Advanced Tools and in the Authentication section click on Set up single sign-on (SSO):
This will take you through to a configuration screen. Make sure the checkbox next to Enable Single Sign-on is ticked, and then enter the following values:
Sign-in page URL: https://adfs.yourdomain.com/adfs/ls/
Sign-out page URL: https://adfs.yourdomain.com/adfs/ls/
Change password URL: https://sts.yourdomain.com/startersts/users/password.aspx
Verification certificate: Upload the ADFS Token Signing cert (.cer file) which you can obtain from the AD FS 2.0 Management Console (under Service > Certificates). Remember to click Upload.
Check the box next to “Use a domain specific issuer”.
Enter some network addresses into the Network masks box if you wish.
At this point Single sign-on is configured and enabled. Note that this will take immediate effect on your access to Google Apps services so beware! However it does not affect your login to the admin console – that is always accessed via a manual login, so you can get in and turn it off again.
Configure ADFS
Open up the AD FS 2.0 Management Console and navigate to the Relying Parties section. Click Add Relying Party Trust and follow these steps:
Choose Enter data about the relying party manually
Provide a name for the trust (not important, only so you can easily identify it)
Choose AD FS 2.0 profile
Tick Enable support for the SAML 2.0 WebSSO protocol and enter /acs">https://www.google.com/a/<your-domain>/acs into the Relying party SAML 2.0 SSO service URL
Enter google.com/a/<your-domain> as the relying party identifier
Complete the wizard.
Then click on the newly added item and click Properties. Click on the Signature tab and click add:
Here we add the Token Signing Certificate – it must be the same one that we uploaded in the Google admin console, and this should be the ADFS Token Signing Certificate.
Once you’ve done that click OK to close the Properties dialog.
Now click Edit Claim Rules and click Add Rule:
Select Transform an Incoming Claim from the Claim rule template drop-down:
Give the rule a name, select E-Mail Address as the Incoming Claim Type, set the Outgoing claim type to Name ID and the Outgoing name ID format to Email:
Finish the wizard.
Test
I’ve assumed here that you’ve already got your custom STS configured as a Claims Provider in ADFS. To test the end-to-end service, visit http://mail.google.com/a/<your-domain>. You should get redirected to ADFS. Choose your STS and then enter your credentials. You should then be redirected back to Google Apps and arrive at your mailbox, logged in.
If you hit problems, check these items:
- You’ve got the correct certificate uploaded to Google Apps and configured in ADFS
- The time on the ADFS server and custom STS servers is correct
- Google Apps SSO configuration is correct
- If all else fails, try Googling!
Loading tweets...
36 comments
Skip to comment form ↓
Dominique
January 18, 2012 at 11:08 pm (UTC 0) Link to this comment
Man, that was exactly what i was looking for. I will try to implement it tomorrow.
Best regards.
shuggill
January 30, 2012 at 5:05 pm (UTC 0) Link to this comment
Great, glad it helped – let me know how you got on
Scott Eastin
January 21, 2012 at 3:42 pm (UTC 0) Link to this comment
Great post with clear steps. I found that when initiating a SSO call from ADFS to google apps you have to set an outgoing claim rule from ADFS to Google with an ADS attribute store. One question, how did you solve the sign off redirect issue from Google Apps back to ADFS?
shuggill
February 3, 2012 at 10:08 pm (UTC 0) Link to this comment
Hi Scott,
Google Apps expects a Name ID formatted claim, so you do need some claim transformation rule to convert whatever incoming claims you have (in my example an email claim, but from AD it could be the UPN or account email) to the required outgoing claims.
I haven’t solved the single-sign out issue yet – all I can see is that I get an ADFS error when trying. If you make any progress I’d certainly be interested.
Glen Colby
July 30, 2012 at 5:30 pm (UTC 0) Link to this comment
Hi, we used your blog to get Single Sign on working and it helped immensely, so first I just want to say thank You.
I was wondering if you were ever able to get the Single sign out to work correctly?
shuggill
July 31, 2012 at 6:58 am (UTC 0) Link to this comment
Thanks Glen, glad it was helpful.
I have not done any further work on Single Sign Out yet – but watch this space!
Benjamin Collins
February 1, 2012 at 8:45 pm (UTC 0) Link to this comment
I’m sure I just don’t understand ADFS well enough, or maybe I’m not understanding what you’re trying to do, but why do you need the custom STS? Isn’t ADFS an STS?
shuggill
February 3, 2012 at 10:06 pm (UTC 0) Link to this comment
Yes, ADFS can provide authentication using it’s built in Active Directory claims provider trust. However, in my situation the user credentials are stored in a custom database (happens to be MS SQL Server but could be anything) and therefore I use a custom STS to provide authentication. If you only need Windows Authentication (i.e. because your clients are logged on to a Windows domain that your ADFS server has access to) then all you need is ADFS.
Jason
February 7, 2012 at 5:08 pm (UTC 0) Link to this comment
In regards to the token signing certificate. Will the auto-generated one, which is my internal FQDN, work? Or will I have to issue a new cert with the servers external FQDN?
shuggill
February 7, 2012 at 9:04 pm (UTC 0) Link to this comment
The auto-generated ADFS token signing certificate will do fine, in fact I’m using the auto-generated one. I haven’t seen any performance issues with using a non-publicly issued cert for this.
Nia Hostetler
February 10, 2012 at 4:31 am (UTC 0) Link to this comment
Thanks a lot for the article post.Really looking forward to read more. Really Cool.
Jason
February 13, 2012 at 3:17 pm (UTC 0) Link to this comment
Thanks for the info on the cert. Apparently my problem is that the NameID Element is missing from my SAML Response. Thought I followed your directions to the letter, but I may be missing something.
Jason
February 21, 2012 at 9:24 pm (UTC 0) Link to this comment
Following your directions for the claim rule NameID is never set in the SAML Response. If I create a claim rule using LDAP attributes I can get it working, but that is gonna make things difficult for me. Got any suggestions?
shuggill
July 4, 2012 at 7:45 am (UTC 0) Link to this comment
Hi Jason,
Have you tried different types of claim type in ADFS? I suggest playing around with the format field too. Then if you can run a HTTP inspector like Fiddler, you can check the SAML response from ADFS yourself.
HTH,
Sam
izo
March 29, 2012 at 2:13 pm (UTC 0) Link to this comment
I make everthing okey.
my domain is istanbulticaret.edu.tr but my google domain is icu.edu.tr I am not using STS only active directory authentication. what shoul I have to make on transform rule.
google redirect to my server I enter usernmae and password but do not accept the password.
thanks
vinny
April 9, 2012 at 2:26 pm (UTC 0) Link to this comment
Hello. Thanks for the step by step information. We have a windows 2003 environment on campus. We are in the process of provisioning and setting up Google Apps for our students using Single Sign On option for authentication and are looking to use ADFS 2.0 on a Windows 2008 R2 server. Can ADFS 2.0 co-exist in a 2003 environment? If so, does authentication really work in the 2003 environment using ADFS 2.0 or do you need at least one 2008 domain controller in mixed mode and another ADFDS server as well?
shuggill
May 7, 2012 at 2:12 pm (UTC 0) Link to this comment
Hi Vinny,
I’ve not had any experience mixing environments however I would imagine that you could easily add the Windows 2008 R2 server to the 2003 domain and run ADFS 2.0 on it. I don’t think there is anything special about the AD requirements.
I’d be interested to know how you get on, do post back.
Lucas Lacroix
April 24, 2012 at 2:54 pm (UTC 0) Link to this comment
We had used these steps to setup our Google SSO solution over a year ago, and it broke the other day. Part of the issue was due to certificate expiration. The other part had to do with the fact that the SAML response no longer contained the NameID element.
We had to create an “Send LDAP Attribute as Claims” rule that extracted the “E-Mail-Addresses” as “E-Mail Address” claims, and further had to create a transform rule to take that claim and output it as a NameID element with the EMail format.
I had to modify the transform rule because the “format” attribute of the NameID element in the output did not match what Google was looking for. Namely, ADFS was outputting “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress” when Google expected “urn:oasis:names:tc:SAML:2.0:nameid-format:email”. What’s confusing about this in particular is that it is an ADFS 2.0 server and the RP is a SAML 2.0 profile, so why would this output a 1.1 format identifier?
shuggill
July 4, 2012 at 7:48 am (UTC 0) Link to this comment
Hmm interesting. Sounds like I should revisit this in light of some changes at Google. Vis the versioning, this might be a confusion between the SAML protocol and the SAML token format.
Mario
May 4, 2012 at 6:24 am (UTC 0) Link to this comment
@Jason
How do you create a claim rule using LDAP attributes? I am having the same problem with no NameID being set in the SAML Response.
Mario
May 4, 2012 at 6:46 am (UTC 0) Link to this comment
That’s ok. I figured that out using the following link:
http://www.john-james-andersen.com/blog/service-now/ad-fs-2-0-working-with-servicenow-saml-2-0.html
See section:
AD FS Relying Party Claim Rules
dennis.m
May 25, 2012 at 5:30 pm (UTC 0) Link to this comment
Thanks for a very helpful post. You’ve explained almost everything. Is there any chance you could explain more? I’m trying to configure Google Apps SSO to work with ADFS on Active Directory. The part I don’t understand is “I’ve assumed here that you’ve already got your custom STS configured as a Claims Provider in ADFS” I not using a custom STS. I just want to use ADFS and Active Directory. I’ve found nothing on the internet nor Google Apps help to configure this part. Could you explain or point me to a resource?
shuggill
July 4, 2012 at 7:52 am (UTC 0) Link to this comment
Hi Dennis,
If you are using Active Directory then it is very simple – all you need to do is make sure that your ADFS server (if it’s a different machine to your Active Directory domain server) is joined to the Active Directory domain that you wish to use. ADFS comes with a built in AD claims provider for the domain that it is part of. No further config required.
Devin
June 7, 2012 at 5:13 pm (UTC 0) Link to this comment
Hi, I was wondering how this would affect users who add their gmail to their mobile devices. Would that still work? since Google potentially no longer has their updated passwords.
shuggill
July 4, 2012 at 8:00 am (UTC 0) Link to this comment
As far as I can see iPhone access is authenticated directly with Google, rather than through ADFS (see http://harwoodhill.com/blog/2011/05/iphone-password-error-with-google-apps-sso/). Therefore I think you would need to set up some sort of password sync between the two.
Prasanna
June 22, 2012 at 8:42 am (UTC 0) Link to this comment
Hi shuggill,
I have got few enquires in providing SSO access to google apps. Can u give me your email id so that I can email you.
Thanks
Prasanna
shuggill
July 4, 2012 at 8:06 am (UTC 0) Link to this comment
Yes it’s sam [at] huggill [dot] com
Scott Eastin
August 22, 2012 at 1:53 am (UTC 0) Link to this comment
This should solve the sign out problem for Google Apps and ADFS 2.0
http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/bcab09d1-9f33-4ef9-a54d-dbeace628771
Anita
October 4, 2012 at 7:30 am (UTC 0) Link to this comment
Hi Shuggill,
I have configured SSO using ADFS for Google Apps.When we tried testing the configuration by entering the url http://mail.google.com/a/ it gets redirected to ADFS but at this point I get a google server error.
Is this error because the domain created by me is not registered on the internet and is a local domain for testing purpose only.Do I need to buy a public ip and domain for successful redirection ?
Thanks and Regards,
Anita
shuggill
October 16, 2012 at 9:40 am (UTC 0) Link to this comment
What is the domain you are usng?
web page search engine optimization
October 6, 2012 at 3:03 pm (UTC 0) Link to this comment
Sweet blog! I found it while surfing around on Yahoo News.
Do you have any tips on how to get listed in Yahoo News?
I’ve been trying for a while but I never seem to get there! Cheers
Samvit
October 9, 2012 at 8:15 am (UTC 0) Link to this comment
Hi Shuggill,
I have tried to configure SSO for Google Apps using ADFS but I’m getting the following error:
“Server Error: We are unable to process your request at this time, please try again later.”
This is what I have done:
1. I have an AD (it’s on a virtual machine) — NOT on public network
2. I configured an ADFS on that server
3.I enabled SSO for Google Apps
4.I added a Relying Party Trust in ADFS
5.I tried to open Gmail service for my domain
6.I am getting redirected to ADFS
After I enter the username and password , the error message appears:
“Server Error: We are unable to process your request at this time, please try again later.”
Do I need to make any DNS entry for my DC ? I followed your blog but I was not able to successfully configure it.Can you please help..
Regards,
Samvit
shuggill
October 16, 2012 at 9:32 am (UTC 0) Link to this comment
When you get the error message what is the URL in the browser? Is it ADFS or Google? If it’s ADFS, you can open the Event Viewer on the ADFS server, then expand Custom Logs and the ADFS node to see ADFS related events, that should show you some further details on the error.
Radhika
October 10, 2012 at 7:34 am (UTC 0) Link to this comment
Hi Shuggill,
Thanks for the step by step information!
I’m getting a Google Server error after having configured ADFS 2.0 using the steps you provided. When I investigated the HTTP headers, I found that the decoded SAML response contains an “EncryptedAssertion” block instead of an “Assertion” block. How do I change this encrytion setting in ADFS? Also, since I am using AD as an Identity Server do I need to make any changes in the “Transform Claim Rule” wizard to convert incoming claims to UPN or account email instead of an email claim like you mentioned in the second comment above.
Awaiting a quick relpy.
Thanks!
shuggill
October 16, 2012 at 9:26 am (UTC 0) Link to this comment
Hi,
ADFS will be encrypting the response IF you have set an encryption certificate up on the ADFS configuration for the relying party. To check / change this, open the ADFS configuration application, click on the Relying Party Trusts item on the left hand tree, and double click on the relevant item on the right (the Google Apps entry). Click on the Encryption tab and remove any certificates there.
Once you’ve saved the changes try again, and you should see that ADFS is no longer encrypting the contents of the token.
Paras
November 4, 2012 at 10:36 pm (UTC 0) Link to this comment
Great article – being able to provide SSO to Google Apps from Active Directory (or ADFS) will help with a solution that I am proposing where by users in the organisation from across the globe need to collaborate and given the current IT environment of this organisation – Google Docs is perhaps a better bet than trying to implement any type of collaboration or content management solution