5. Choosing standards for security assertion messaging

Security assertions are passed between Service Providers and Identity Providers in ‘real-time’. To enable identity federation all parties need to agree on standards for the format and structure of the security assertion message and transport protocols.

More detail on these is given in Appendix A.

Selection criteria

The selection of such a standard is largely driven by three key requirements:

• The use cases or functionality required.
• Support for an approach to the notion of federated identity and the Single Sign-On user experience. (Note that some features, such as the ability to select an identity provider - where there is more than one available - and ‘Single Logout’ are available in most security assertion messaging standards except SAML 1.0. Newer features such as the ability to perform account linkage are limited to the Liberty protocols and the SAML v2.0 standard).
• Widespread product and vendor support through the availability of a range of commercial or open-source applications.

Proprietary or standards-based solutions?

It is usually better to select a standard technology if one is available in preference to building a custom solution. Although building a custom messaging solution or modifying an existing proprietary solution may initially appear attractive, it is necessary to consider the costs and risks associated with:

• Designing a solution
• Implementing a solution for each environment to be supported
• Maintaining the solution to fix bugs, resolve security issues, implement product enhancements and to support users
• Reliability of the solution
• Lack of interoperability with standard products.