Matthew Knott

Last year, we hit a huge breakthrough in work where we got Single-sign on to Google apps working through our SharePoint based Learning Platform, and began looking at ways to integrate the functionality of SharePoint and Google Apps. My first instinct was to share how we did it and how we forsee this being used in the future. 

Despite my best intentions, I talked about what I was planning to write with my manager, and he quite rightly pointed out some pretty good reasons why I can't just go sharing the whole thing. This stopped me taking the series further than the preview article I wrote. After seeing the amount of interest in the original proposal, I thought I'd try to take it as far as possible. I'm not going to include any code, or give specifics about the SAML process.

How we did it

Okay, so not the complete explaination you may have hoped for but I'll talk about how we did this from an infrastructure perspective.

The way the single sign-on work in effect is that a user accesses their respective Google app (e.g. https://docs.google.com/a/domain.com) and they are redirected to a single sign on page on our portal. Firstly, this page is only visible to authenticated users, so the user is prompted to sign in to SharePoint. 

Once the user signs in to SharePoint, We query an SQL table we've created to see if we have any record of the users google apps account. You could store this value as a user profile property but we've opted to use a database because there can be multiple accounts linked to multiple domains.

If there is a value, the username is passed back to Google and the sign on process is complete, if not, we ask the user to enter their Google username and password. If authenticated, the username is added to the users record, then passed back to google, and the sign on process is completed.

Essentially that's it, after the initial account match up, there's no user interaction unless the account has been locked or requires a Captcha response to be supplied to access Google.