Case study: creating services with UK access management federation

The UK access management federation provides access to services for users based at participating institutions in the UK.

This case study is a brief summary of the process associated with registering a service with the UKAMF and the advantages (and disadvantages) of doing so.

Process

To register a service (assuming it's accessible with a web browser!, e.g. via a portal), it is necessary for the organisation registering the service to be a member of the federation - it thus has to sign up to the Rules of Membership, which involves very likely someone in the organisation liaising with the organisation's IT infrastructure staff, IT security staff, and legal/contracts staff - and assuring each set that their requirements can be met. So a new service

• must be developed to accept federated login, typically via either mod_shib or SimpleSAMLPhp.
• must be checked against organisation-internal checklists to ensure that the organisation can comply with the RoM
• must be registered with the federation as described in the UKAMF processes, and have admin, technical, and support contacts.

Thus, there is some overhead in registering a service compared to setting one up and just use username/password. More people are involved and more steps are taken. There is likely some debugging of the new service with UKAMF support, typically done at an interim stage where the service is registered in the UKAMF but not advertised. There will also be some ongoing maintenance, such as changing metadata or registered contacts, as well as potentially incident handling.

So why register services - why not just use username/password and be done with it?

First, username/password is not very secure as users are likely to use insecure or reused passwords, to share passwords with each other, to forget them, or to retain them even when their rights to use the service expires (typically that they are no longer at the organisation that sponsored them).

Secondly, the process of maintaining username/passwords, supporting the identity management process, and keeping the account data up to date also requires some effort which now lies with the service provider's staff, rather than the UKAMF or the user's home organisation.

Third, and perhaps most importantly, within the federation, users' identities come with strings attached. Users (or rather their home organisations) have signed up to the RoM which means that they hold the users responsible for their use of the service.

Fourth, particularly if users use several services registered with the UKAMF, they will find it easier to use because they will authenticate to their home organisation only once, yet they will be able to access all the services (assuming they have permissions).

Things to ponder

• By default the UKAMF has very few attributes, only targeted id, principal, home organisation, and entitlement.
  • Targeted id is very common but makes it hard for users to access distributed infrastructure services because their identity changes at every access point.
  • Home organisation is useful mainly for organisational subscriptions or for statistical purposes.
  • Entitlement needs to be set by the home organisation IdP.
• Attributes may be used only for account/presentation, basic authorisation (e.g. institutional subscriptions), and statistical purposes - so more advanced authorisation use cases are not covered. Entitlement could be used but needs to be set.
• Most services will require an email address as a means of contacting users about the service. As the IdP does not provide it, the service provider will need to go through a registration process for new users, ask for their email address and permission to use it, validate the email address, and maintain that separately in an account database.