Google Apps was deployed at the University of Cambridge to provide calendar functionality to over 40,000 users across 100 departments and 32 colleges. A Java-based single sign-on application called gAuth was created to integrate Google authentication with the University's existing Raven authentication system. While rollout went smoothly, ongoing issues included conflicting accounts and support responsibilities. Usage grew steadily, with unique daily and monthly users increasing since the October 2010 launch.
1. Google Apps @ Cambridge
What we did
Jon Warbrick
University of Cambridge Computing Service
jw35@cam.ac.uk / @jw35
2. The University
of Cambridge
100+ departments
32 colleges
40,000 users
“A loose affiliation
of warring fiefdoms”
3. Handy building blocks
• University Computing Service
• even if it doesn’t set policy
• User Administration Database
• Raven: Web Authentication system
• including a Shibboleth IdP
• A 2008 UCS trial of Google Apps
4. What do we want?
A Calendar!
Perhaps other things, later...
5. To stay within the law
http://www.cam.ac.uk/cs/googleapps/google-apps-cambridge-contract.pdf
Photo: CC BY-SA 2.0 Steve Punter http://www.flickr.com/photos/spunter/3363326374/
6. General Plan
• Google Apps for Education
• but just Calendar to start with
• Use cam.ac.uk domain
• Web SSO using Raven
• Automatically available to everyone
• Minimum ongoing staff involvement
• Rollout September, for October, 2010
20. Account management
gAuth
Raven feed
User admin.
database
reconcile- reconcile-
admin google
Status: Google
•[Unknown]
•Current
•Blacklisted
•Cancelled
•[Deleted]
21. Implementation
• gAuth: Java webapp in Tomcat
• Batch processing: Java run by cron (!)
• (Live/stanby) pair of VMs on Xen cluster
• Local Postgress database; Slony1 replication
• Manual service address transition
22. Plain sailing?
• Account issues
• Pre-existing cam.ac.uk domain
• ‘g’ ‘o’ ‘o’ ‘g’ ‘l’ ‘e’ not allowed in domain
names
• Calendar sync, iPhones and other
mobile devices
• Support. Do you or don’t you?
Photo: CC BY 2.0 sailorbill http://www.flickr.com/photos/sailorbill/2435667146/
23. Account Issues
• Conflicting accounts
• Google apps vs. Google consumer
• foo@cam.ac.uk != foo@cam.ac.uk
• The ‘New Authentication Architecture’ transition
• Conflicting accounts renamed
• Loss of multiple login
• The 62 ‘other’ Google services
Photo: CC BY 2.0 sailorbill http://www.flickr.com/photos/sailorbill/2435667146/
24. Deployed October 2010
Number of Accounts
http://www-uxsup.csx.cam.ac.uk/~jw35/google-usage/
25. Deployed October 2010
Unique users per day
http://www-uxsup.csx.cam.ac.uk/~jw35/google-usage/
26. Deployed October 2010
Unique users per month
http://www-uxsup.csx.cam.ac.uk/~jw35/google-usage/
29. Any questions?
Jon Warbrick
University of Cambridge Computing Service
jw35@cam.ac.uk / @jw35
Hinweis der Redaktion
Introduce self\nQuestions welcome as-and-when\nA SSO and IdM case study. About May->September 2010\n
University of Cambridge is an unusual place - some of this may not apply to you\n
We do have some useful building blocks\nNote that we didn’t use Shib (will explain why later)\n
Have e-mail, websites\nDon’t have Docs equivalent, or chat, but don’t have any demand either\nDo have demand for a calendar - go for that as ‘extended pilot’\n
Notably:\nData Transfer outside EEA – DPA 8th principle - Compliance with Safe Harbor principles\nUser's Privacy & Data Processing – DPA 7th principle:\n Use of customer data only in connection with provision of service\n Measures against unauthorised access\npostmaster@ & abuse@ addresses\n\n\n
Use of cam.ac.uk domain a nod to possible future gmail\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
ANNIMATION\ngAuth is an ‘invisible’ service, hence dotted outline\nAll this is ‘old’ hat’ web redirection authentication\nMost of this is invisible to users\n
Google code now marked ‘deprecated’, but what we used earlier\nDidn’t use Raven Shib because a) still 1.3; and b) needs ‘special’ config; and c)wanted to do other things\nHaving our T&Cs was useful for DPA etc. compliance\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
ANNIMATION\nOn the way back through gAuth, having worked out who we have\nCreate if doesn’t exits, update else\nCreate seems to work reliabably (slightly to my surprise!) \nJava version of API, to integrate with gAuth SSO code\n\n
\n
\n
Also wanted/needed to support non-Web access\nVery like ‘application-specific passwords’ in new Two-step verification\nBorrowed ‘Token’ idea from eduroam - always retrievable\n
Need to clean up departed users (DPA if nothing else)\n Except our users tend to come back!\nLoss of Raven not good enough --> because of Token\nForced into gAuth database to store retrievable token \nMain gAuth code also enforces consistency\n\n
Not Heartbeat because of Slony issues\n
Account issues expanded on the next slide\ncam.ac.uk was ‘Comunity Managed’ edition\n a problem because a) users might have left; and b) included Docs/Sites\n couldn’t check departed users till agreement signed\nWanted to use google.cam.ac.uk to allow for mslive.cam.ac.uk. Couldn’t.\nStill some re-authentication problems on iPhone. Caching?\nDon’t under-estimate the support cost, if you provide support\n
Turned out that quite a lot of people (20%) had conflicting accounts\nNew Auth Arch hit soon after launch, transitioned May 2011\nBig problem with the 62 is where email address is meaningfull - e.g. Google Groups\n
\n
Note Saturday/Sunday\n
The theory is that we are not picking up many new users\n