SSO v3: Scalability and manageability
One of the primary reasons for wanting to create a new Single Sign On (SSO) system is so that we can work better with the much wider range of users and services that want to use SSO.
Servers and developer boxes registered to work with SSO: 64
Logins per day: 9,500
User login checks from services per day: 20,000 (implying each user uses 2 different services per day on average)
Warwick users: 20,000
So, around half of all users login each day to some SSO controlled service. Obviously for a lot of services you can use them without logging in, but you must login to do certain tasks. A lot of users reading pages in SiteBuilder, Blogs and Forums are not logged in (but will login to edit/comment/post).
To manage these numbers more effectively, we needed a more powerful and better compartmentalised system.
Our starting point was the Shibboleth Origin software from Athens. The team at Athens provide a Java based Shibboleth Origin that can be easily integrated into our systems (also Java). From this starting point, we've got up to speed relatively easily with the Shibboleth protocol.
One of the nicest features of the software is the security which uses mutual SSL authentication for more or less everywhere and signed SAML (XML) as the way of getting data securely around.
My other favourite feature is the ability to define which attributes of a user get sent to different client services. So if we only wanted to tell Athens your first name but not your email or full name, we could do so with a simple bit of configuration. But for our internal systems, we could easily configure it to send a lot more detailed and trusted information, thus providing a more secure and private and virtually anonymous way of authenticating to partner services. As long as the partner service trusts Warwick to vouch for someones identity, they will let that user in without knowing their real identity.