Abstract

In this article we look at how an organisation can start to unify some of their IT systems and reduce the number of times a person's identity is stored within the organisation. The most popular execution of this is Single Sign On (SSO).

We'll discuss how it works and some of the advantages and disadvantages of this technology.

What is it?

'Single Sign On' (SSO) is a technical process that allows a user to log into one computer system and gain access to another system without having to create a second account or needing to login to other system separately.

An SSO solution can exist for any type of Information System but for the basis of this article we'll assume that all of the systems are internet based and provide different types of functionality to the user.

In our example we will be using the Australian sports sector as an example of the need and execution of some SSO solutions.

What is the need?

A National Sporting Organisation like Netball Australia will offer its community of interest a number of online services that require some form of account management. These systems can include:

• A membership system if I want to play Netball
• An online shop if I want to buy Netball gear
• An online ticketing system if I want to go to games
• An online training system if I want to do eLearning courses
• An online accreditation system if I want to undertake certification

The list can, and actually does go on. One sport we work with realised that a person's contact details could exist on up to fourteen systems. If a user rang up and said “this my email address can you please update my records”, they just wouldn't know where to start searching so they just gave up on updating records.

Each of the systems above are often provided by different vendors, as one system to 'rule them all' just does not exist in the market. So the emphasis is then on how to make these systems interact or 'play nice' with each other in such a way that the following needs can be met:

• Users have only one account for all systems
• Users login once and get access to all systems
• Reduce the cost of managing user records
• Organisations have one user record per person

The last point is becoming critical in sports or any membership based organisation. If a member wants to update their details then you can't log into fourteen systems and update all of them for that one user. Ideally you want the member to be able to login to one system and change their own details.

Some of the geek talk

When you dive into the world of SSO there are a lot of weird terms that we need to get our heads around.  Here is the simple version.

• Principle - A User, regardless of their role or permissions. They could be an administrator, learner, member, umpire or coach for example. I don't know why they called them a Principle, so like everyone else I'm just going to call them 'Users'.
• IdP - Stands for the Identity Provider, this is the system (website) that is the central manager of who a person is. Two of the very popular IdP's are LDSAP and Active Directory.
• SP- A Service Provider is a system that provides a service to the authenticated user. This is sometimes also referred to as the Relying Party
• SAML - Security Assertion Mark-up Language is one of the three common technologies that allow two systems to share Authentication/Permissions data .
• OAuth - Is an open security exchange standard that allows two servers to share resources over HTTP using authentication tokens. If you want one server to send a report of enrolments to another server the link will most commonly be secured by OAuth. It can also be used for user authorisation. For example, logging into a website using your Facebook account is commonly achieved using OAuth.

A sometimes confusing aspect of IdP and Service providers is that a Service Provider is often the IdP as well. For example a Membership system where a person can create an account, login and join clubs and teams operates as an IdP (account management) and as a Service Provider (Membership services).
One of the upcoming challengers in managing all of this is to try and split the IdP service away from the Service Provider.

How it works

Let say that we want to connect two systems together so that the learner does not have two accounts, we'll use the Netball Australia example and go through the steps.

 

• Alice is a Netball player, and has been issued a MyNetballID 123456. This number was generated by her club in the Membership system and forever more that shall be her ID.
• Alice wants to view her details and goes to http://my.netball.com.au and selects get started. She can use this screen to create a login account to MyNetball, so she now has access to the Membership system.
• She logs into the MyNetball Membership system and sees that she can do some online learning to become an umpire. She clicks on the link to go to the eLearning system.
• The two sites shake hands using SAML and the membership system says “I have a user called Alice with a membership number of 123456, do you have an account for her?”.
• The eLearning System says “No, I don't but I'm configured to create new accounts, give me her name, DOB, Email address and MyNetball ID”. The eLearning system then creates Alice's account.
• She can now do her learning and come back at any time to continue her studies or do more courses. She will always login to the membership system and then jump over to the eLearning system.

 

It's important to note that the Alice will never log into the LMS and it will never store a password because her authentication is totally managed through the Membership system.

Complications

OK, so life is never simple. The first complication of SSO is getting started. How do we set it up, and what data set do we start with? Most membership systems have legacy data. How clean is it? Do we have 3 records for Alice, or maybe we also have one partial record for Alice's Mum? Do we want to spend the time, and money, cleaning this up which can be an enormous undertaking. Or, do we want to start afresh and require new user accounts for all members, which would cause just a bit of unrest in the ranks.

It is also worth thinking about doing an export of the membership data of all the current users in the Membership System into the LMS. This way there is a good starting point between the two systems with a good one-to-one relationship between accounts.

Next, at some stage, Alice will want to change her details like her email address. Her email address is an interesting one because the eLearning system needs her current email address to send her reminders and certificates.

Managing this is easy enough if the two system can share updated contacts.  So let's imagine that the example above is configured to 'Update' details when Alice logs in.  Here's how it works.

• Alice logs into the membership system and changes her email address.
• She then wants to do some eLearning so she then jumps over to the eLearning system.
• The two systems are configured to share and update details so when she arrives at the eLearning system the authentication process brings her name, DOB, phone numbers and email address with it.
• The eLearning system says “Hey, I notice you've changed you email address I'll update your records here as well”.

This all works fine except it relies on the user to go from one system to another to have their records updated. What if Alice does not do a lot of eLearning and doesn't go to the eLearning system very often?

She may only do one course to get accredited and have no interest in other courses. When the eLearning system tries to send her a reminder three years later that her course is about to expire then it may have a very old email address on its files.

There are three solutions to this:

• The membership system is programmed to update in real time all the dependant service providers it knows about when a user edits their details.
• The service provider system in affect is programmed to know nothing about Alice except her MyNetballID, whenever it wants to do something with her records it pulls her current details from the Membership system.
• Finally you could configure the two systems to periodically share critical information like email address.  This could turn into millions of records being send between the two systems on a batch process.  So once a month the eLearning system asks the Membership system for a list of all users with their MyNetballID, Email address, and maybe financial status.

All of these solutions have hairs on them. Firstly, it means the vendors have to maintain a lot of code. Also, imagine if one membership system supports links to multiple eLearning systems, they have to develop literally thousands of lines of code for each link they want to support.

The alternative here, is to just live with it.  OK so some learners, sometimes don't get the notifications they might expect.  Not ideal, but always worth considering.

Working with Vendors

Of course the people who have to do all of the work here are the vendors of the different systems.  There is a lot of code to develop and test and then a lot of logic to work through to make sure that the expected customer solution is rolled out effectively. And just because a vendor develops an SSO capability between two systems does not mean that a third system can just be plugged into the SSO eco-system.

The issue that most vendors face is one of “Should I do SSO”. Many vendors are reluctant to develop these bridges because they are costly, and I think they are often faced with customers who think you 'just do it'.

It is no stretch of a lie to say that to bridge two systems for the first time is about an AU$40,000 job. The second one can be cheaper but there is still a lot of new work and testing that needs to be done. 

This investment is one that many vendors find hard to justify, especially if they are faced with a customer who is unable to think through all of the requirements and accept the limitations of SSO.

However, if the vendors and customer can work together and create a SSO solution which works as expected then the user would experience a seamless experience throughout without any idea of the time and effort involved in creating this.

Summary

OK, so that is a bit of a primer on SSO and how it works and some of the limitations there are. 

It would be naive to suggest that we 'just turn on' SSO.  There is a lot of work to do and a lot of testing. It's also important to note that SSO is not a perfect solution, it does comes with problems that sometimes can't be resolved.

In part 2 of this article we will look at implementing SSO in a multi-tenanted system, which has some unique considerations.

Read Part 2