What goes on when you login to a Single Sign On controlled web site? From the user’s point of view, not much: you may have to select your institution from a long list of possible site, but once you have found the right one you just type in the required username and password and you are in.
From the system point of view there is a lot of going on behind the scenes activity. The whole login process has to be tweaked so that the information received about a logged in user matches what the website, better the Service Provider (SP), expects.
When a user succeeds in logging in a package of information is generated and shared with the SP in SAML format. SAML is an XML format. Generally only the minimum amout of information required to access a site is released, in ways designed to prevent tracking of users and avoiding spam emails.
The SAML released can be viewed in the Firefox Add-On SAML Tracer. But SAML is meant to be machine rather than human-readable. If there is a problem with access to the site it may well be because of an issue with the attributes released not matching those expected by the Service Provider.
There is a quick way of viewing the attributes released bu building a URL that looks like https://login.library.dmu.ac.uk/oala/sso-debug?entityID=<entityID-of-SP>. For example:
You will need to login with your own DMU Single Sign On details. The resulting Single Sign On Debug pages tell you where the information is being sent; the names of the SAML Attributes being released and the values associated with these attributes.
If there is an issue with logging in to a Service Provider’s resources, it might be worth checking the attributes released to ensure that the ones expected are in fact present.