Thursday 17 February 2011

Google Apps: SSO and IdM at #GUUG11

Here are some slides from a presentation I gave on Google Apps SSO and Identity Management at the inaugural 'Google Apps for Education UK User Group' meeting at Loughborough University on 15th February 2011:

2 comments:

  1. Jon,

    Great Stuff.

    Would you mind share with me some details for the Non-web authentication? In term of "Using tokens with Google Apps @ Cambridge", is the token just another password that was sent to Google Apps?

    Thx,

    Hongbo

    ReplyDelete
  2. Almost. When you turn on Google's SSO option for your domain then two things happen. The first is that when your users would previously have been prompted in a web browser for their username and password they will be redirected to your local authentication service. The second is that the user loses access to the Google-provided pages for managing the password associated with their account.

    However for non web based access (so calendar syncing, IMAP, API access, etc) the Google password is still what's used for authentication. So what we did was provide a simple web interface that will set and re-set the password on a users account, and indeed tell users what the current value is, and we protected that with our local web authentication service. For historical reasons we called this a 'token', because our local documentation makes a distinction between a 'password' (that should be known only to you, should not be written down or stored anywhere accessible and which can't be recovered if lost) and a 'token' (which is typically an auto generated random string and which is expected to be stored in the configuration of calendar and mail programs, etc.), but really (shhh!) just a password. We made 'tokens' automatically generated random values mainly to stop users setting them to the same string value as any of their other important passwords.

    Um, and that's it. We probably shouldn't have used the word token because there's obvious confusion between this usage and 'hardware tokens' (i.e. RSA SecureIDs) but we couldn't come up with a better word. We should also have distinguished more carefully between the different 'tokens' that we use - we've had at least one very confused user and confused Help Desk who failed to realise that the 'token' used to access eduroam was not the same thing as the 'token' used to access Google Apps!

    Does that help?

    ReplyDelete