Given that I am working on applications and security, I started looking at OpenSAML. Documentation is a bit skimpy, so I decided to collect my experiences in a cookbook style. They’ll be here.
OpenSAML provides support for writing SAML 1 and 2 compliant code. SAML, the Security Assertion Markup Language, is an XML based set of specifications and profiles defined by OASIS for exchanging assertions about identity and access rights. The specifications are available here.
Profiles collect a set of assertions, protocols, and bindings into a coherent set for a specific purpose. The most common profile referred to is the Web Browser SSO profile, which deals with providing Single-Sign-On services to Web Applications. By implementing this profile you can allow users to log on to a set of Web applications once, and have the user’s identity made available to those applications. Signing off (logout) is also included, ensuring that the session will no longer be valid for all connected applications.
The Identity Provider Perspective
An Identity Provider, shortened to IDP, is the service that will manage the session. It is also the main responsible entity for checking the user’s identity, although it may delegate this task to yet another entity. The application, or Service Provider (SP), needs only the IDP as peer to talk to. The IDP will normally return only a session identifier when the user has been identified, as the user’s browser is used a transportation medium for the message containing the verdict, the Assertion. The SP will need to make a direct call to the IDP to obtain some kind of identification of the user. Because this by-passes the browser, the front-end, this is called a Back-Channel call. IDP and SP can use additional security measures to protect this Back-Channel call, such as a client certificate, to further protect the user’s privacy. Note that some implementations of this profile skip the part; the Dutch eHerkenning standard, which is standardized by the Dutch Government for use by corporate and governmental organizations as SP where the users are representatives from corporations. The eHerkenning standard does not implement SSO and thus has no session concept. Rather, the IDP directly returns the corporations registration number with the chamber of Commerce and a unique, but anonymous, identifier for the user. EHerkenning guarantees to the SP that the user is a representative of the registered corporation and optionally that the user has been registered as authorized for an specific service.
The Service Provider Perspective
The Service Provider needs to be registered with the IDP, which means exchanging SAML Metadata. This metadata tells the SP where the IDP’s services can be found on the Web, and what Binding they use. For the IDP they provide the SP’s URL where the user is expected to go after successful identification, although alternative URLs may be specified. Both parties can optionally provide the public certificates which can be used to check message signatures or encrypt message content. The SP can now delegate user logon and logout to the IDP, in return for a guarantee on the user’s identity.
Here we collect the actual cookbook part.
Part 1: Configuration and Setup Recipes
Here are the steps for setting up the (Application) Servers.
Part 2: Common Recipes
Here are (SAML) generics bits of code.
Part 3: IDP Recipes
Here are the IDP-side bits of code.
Part 4: SP Recipes
Here are the SP-side bits of code.