This article will try to take a look at, and come with some recommendations on how to handle user identities on multiple platforms.
The most important thing is, and will always be consistent naming! It is not possible for systems to work together if they do not have a shared perception of what identifies a user.
This may at first glance not really be important, since all the IT systems work independently. But there may be situations where these seemingly independent systems need to talk directly to each other.
The basic use case for using a central userdatabase is that administrative personal only need to create the user account one place, and all the other systems will then align, and the user only have to remember one set of credentials.
This will work, if there is never (or will ever be) any direct communication between the sites that uses the shared userdatabase.
Problems will arise from the same model, if for instance LMS 1 and LMS 2 isn't setup to use the same values from the userdatabase. If LMS 1 uses the name that the users types into the login field, and LMS 2 uses the email to identify users. Then any synchronisation between the two will be broken!
The best solution is to have a clear institution wide policy on what can be used as a user identifier. Forming a
SAML
Simple Assertion Mark-up Language is an industri standard widely used in general, and in particular in education.
In SAML there is always three actors; the Identity Provider, the Service Provider and the user. The flow of the authentication process looks like this.
A simplified view with some more details as to what actually is contained in IdP response to the SP (the data that actually goes through the Users browser, but in effect is just forwarded untouched from the IdP to SP. The data shown in this diagram is just a sample, and an actual response will contain much more information.
SAML Attributes
The key-value pairs in SAML that are transferred from the IdP to the SP is called Attributes, and while there is not really a limit to what they can contain, here is a list of some of the more used ones, with the values for a student named “John Smith” from “Example University of Denmark” located in Denmark
| Friendly Name | Name | Example value |
|---|---|---|
| eduPersonAssurance | urn:oid:1.3.6.1.4.1.5923.1.1.1.11 | http://www.swamid.se/policy/assurance/al1 |
| eduPersonScopedAffiliation | urn:oid:1.3.6.1.4.1.5923.1.1.1.9 | student@eud.dk |
| o | urn:oid:2.5.4.10 | Example University of Denmark |
| displayName | urn:oid:2.16.840.1.113730.3.1.241 | John Smith |
| sn | urn:oid:2.5.4.4 | Smith |
| givenName | urn:oid:2.5.4.42 | John |
| co | urn:oid:0.9.2342.19200300.100.1.43 | Kingdom of Denmark |
| schacHomeOrganization | urn:oid:1.3.6.1.4.1.25178.1.2.9 | eud.dk |
| eduPersonPrincipalName | urn:oid:1.3.6.1.4.1.5923.1.1.1.6 | jsmith@eud.edu |
| c | urn:oid:2.5.4.6 | DK |
| urn:oid:0.9.2342.19200300.100.1.3 | john123123123@gmail.com | |
| norEduOrgAcronym | urn:oid:1.3.6.1.4.1.2428.90.1.6 | EUD |
| eduPersonTargetedID | urn:oid:1.3.6.1.4.1.5923.1.1.1.10 | RjcDREQ0ItNxN0MDQ3LTk0NzREMxQTAzNTRjM5C= |
| uid | urn:oid:0.9.2342.19200300.100.1.1 | jsmidth |
Additional resources
https://www.okta.com/integrate/documentation/saml/ Has a more technical description of how SAML authentication works with some more examples.
https://ldap.com/ldap-oid-reference-guide/ have a pretty extensive list of attributes and references to their standards definition. The attributes that are available to you depends on the setup of your IdP, and you should contact the admin at your institution to get an overview of attributes.
https://blog.surf.nl/en/saml-for-dummies/ is another great resource for how SAML actually works.
Comments
0 comments
Please sign in to leave a comment.