If you haven't read Part 1 of this article, then please go back and have a read.
Now that you have read the primer on SSO it's time to think through some tougher concepts in a real world situation.
We are going to talk about the Janison Cloud Learning System (CLS) sub-domain model and SSO. The sub-domain model has a common user database with different sub-portals (domains) within it. Each sub-domain will need the ability to have its own SSO arrangements.
Currently the CLS Ausport tenant is structured as follows:
There are a few other sub-domains on this tenant but the three above will be used as a way to explore the thinking.
The rest of this paper is designed to explore the thinking and development required to move this model forward.
How the CLS authenticates and authorises
The CLS by default uses a username and/or email address combined with a password to manage user accounts. A portal by default is set to use the email address as the user name. So on the ASC site the user records look like this in the database.
When Eve, a user, is created from MyNetball via the SAML SSO then the CLS database looks like this.
Her username is set to her MyNetball ID and her password is null as she will normally authenticate through MyNetball. If she later tried to do an Ausport course and register an account on that site, it would tell her the email address already exists and she can't create her account.
She should be prompted to do a password reset, which would email her a link to rest her password on the Ausport portal.
If she follows through this action and resets her password the database will look like this.
She could login to the Ausport portal using either her MyNetballID or her email address. Hopefully she understands that the Netball portal and the ASC portal use the same user account. That's often not likely so we should include some messaging on the login screen saying that you may have an account on another portal but it is the same account. This can be changed in the string resources on the CLS.
A second SSO system
So if we now introduce a second SSO system say for Swimming which Eve happens to be a member of. She can be created and exist in the Swimming Membership system as well.
It looks a bit like this:
So what happens now is that if Eve has an account on the Ausport portal her username will be set to her email address as in step 1.
In step 2 Eve creates her MyNetball account and jumps over to the eLearning system. This connection uses the Username field as a way to establish if Eve exists and, finding no match, it creates a new account on the LMS for her. Remember the eLearning system uses one userlist for all portals (sub-domains). Eve now has two accounts on the LMS.
Now, if Eve then gets involved with swimming, gets a memberships account and then tries to jump over to the LMS that system will again find no match for a user with a username of '987654' so it, too, will create a new user account. All of a sudden Eve has three LMS accounts and three academic transcripts.
Family Members
It would be nice to think that we could make the SSO account creation routine check for the email address and finding an existing match would link to that account, but that fails to acknowledge that the same email address might be used by several members of the same family.
A common setup in sports is that many members in the family play the sport. Let's assume that Eve has a daughter who we'll call Little Eve and she is 9 years old. Eve doesn't want Little Eve to have an email account so her MyNetball membership is created with Mum's email address.
This is a common use case in sports, and most Membership systems allow for it. So Little Eve gets created in MyNetball, logs in and does some “Game play' eLearning.
What can be done?
In the LMS database there are a few more fields that might prove useful in our quest for a single account for the one person. They are:
The Row GUID: A unique (big) number that the system uses to really keep track of a user account. Eve's GUID looks like this cc4e0bc5-ceb4-e411-827c-0010189e3b8a but let's just use the last block of numbers to make it easier, 0010189e3b8a.
There is also a custom attribute (field) that can be created and possibly used for the SSO sign in and account creation. A Custom attribute can contain any sort of data we want, but for now let's say it contains the unique sports membership number.
So our expanded user table could look like this.
In step 1, Eve has created her account on the Ausport Portal, the Custom Attribute field for any sport that has a sub-domain portal are currently empty.
In step 2 the MyNetball IdP tried to create her account but runs a check first and says do you have any users with this surname, email, and DOB match. First name is not helpful in this instance as we find that people commonly use different First names on different system. Greg vs Gregory, Kathy vs Katherine are common examples. So the MyNetball account creation routine can find a match or two and say, I found these possible matches, if one of them is you then type in your password.
If the password is valid then instead of creating a new LMS account the scripts add a value into CA-MyNetballID. Once the account is created then the SSO can use either the User GUID or the MyNetballID as a means of completing the SSO.
In Step 3 Eve gets involved with swimming, and gets a membership ID from them and tries to jump into their eLearning system. The same checks happen and her CA-MySwimmingID is updated with her Swimming ID and then the Swimming SSO can either use the User GUID or the MySwimmingID custom attribute as the means of completing the SSO.
Nothings perfect
This sounds pretty good, but there are two potential issues can see here:
- If Eve doesn't think the existing account is hers, or couldn't be bothered trying to find her password then she'll just click, “Not me” and a second LMS user record will be created for her.
- If Eve has two little twins 'Little Eve 1' and 'Little Eve 2' and they both use Mums email address to access the MyNetball membership system then potentially it would be hard to distinguish at the time of account creation. This could be overcome at the time of checking by showing their first names, but we get into some privacy issues by showing the first name, surname and DOB of a potential match. Not insurmountable, but problematic.
When all else fails
If we've done our best and tried to reduce duplicate accounts as much as possible then what else can we do?
Merge Record
There is potential to develop a 'Merge Record' script that can identify duplicate records as, for example, “I want to merge these two accounts using the User GUID”. This is a complicated process and once done can NEVER be undone.
The difficulty with this is that the LMS makes use of the User GUID everywhere to keep the most minute details of a learner. When they logged in, what they enrolled in, what session they attended, what page are up they up to in the course. There are literally thousands of fields in the database that use the User GUID, and making sure that every single one gets merged into a single GUID verges on the impossible. It also then forces the LMS provider to remember to continue to edit the 'Merge User' script with any new changes to the Database so that the script continues to work into the future.
Link Record
If we step back a little and think about what these systems are designed to deliver, they generally are about showing some academic transcript.
There may be some potential to develop a Link Record feature that allows a user to enter the login details of their two or more accounts and then when they view “My Transcript” it could show them the results of both accounts.
In keeping with the SSO model, if a remote system requested the academic transcript of Eve, there may be potential to have these scripts show the linked accounts.
Other technologies
There are other emerging projects or technologies that will have a part to play, or will be able to solve many of these issues. These include:
- https://my.gov.au a whole of government single account model in Australia. It remains to be seen if I want my participation in Netball to be linked to a government authentication system but it does have huge advantages.
- Claims based authorisation models
- Service buses like Microsoft Azure Service Bus that use shared access signatures to authenticate and authorisation layers to SSO models.
Summary
In 1995, the Australian government of the day put forward the idea of an Australia Card. A unique number for all Australians and domicile international residents. It was shouted down by all and sundry but if it had got up we may have been able to use a system like that.
Equally if every infant was issued with a Tax File Number at birth we could use that, but alas we live in the real world, and the real world creates the issues mentioned in these two articles.
We don't aim to propose solutions here. This is more an informative article to show the complexity which exists around SSO. To find a solution for any one client we must have all vendors in the room to discuss what is possible and what they are prepared to commit to, and what limitations their client are willing to accept. However, I feel this is a good starting point for the discussion.