About attribute authorities

Basic explanation

The UK federation recommend an attribute authority be used for the most secure transfer of attributes when using the older SAML 1.1 option. OpenAthens have decided to limit support for SAML 1.1 in its modern IdPs and the attribute authority is not implemented; the transfer of attributes over https is considered secure enough for all standard attributes.

If you wish to use the extended attribute set to send information such as real names or email addresses to service providers, you may prefer to limit this to service providers that support SAML 2 via release policy.

If you are in any doubt about a resource, both OpenAthens and UK federation service desks will be happy to check for you.

This affects only the older SAML 1.1 protocol. Almost all connections will use the more modern SAML 2 protocol.

Technical explanation

The attribute authority is what was used to send attribute information directly to a service provider in SAML 1.1 rather than pass it back though the user's browser. The user was passed back to the service provider through their browser, but the users' attributes were sent directly from the IdP to the SP.  Over time it became clear that this approach had significant challenges, not least of which was the difficulty in getting it to work reliably and consistently amongst large groups of IdPs and SPs, especially in busy environments. 

Some federations recommend that this 'backchannel' be used (e.g. UK Access Management federation), whilst others discourage it (e.g. OpenAthens federation, Renater in France).

When the backchannel connection does not exist, SAML 1.1 passes attributes through the user's browser. This is encrypted with SSL/TLS and given the nature of the attributes being passed, this level of security should be sufficient for the few occasions SAML 1.1 has to be used. The extra security afforded by an attribute authority was not deemed worth pursuing in light of the challenges faced by all parties interacting with it, the significant support overhead and the fact that SAML 1.1 was superseded by SAML 2 so many years ago (2005).

SAML 2 supports encrypted tokens which are secure, convenient, and do not require a backchannel connection.

Almost all service providers support SAML 2 and their software should use that over older SAML versions wherever the IdP supports SAML 2 as well.