The SAML2 authentication module is a new addition to OpenAM13. It comprises three new components which work together along with OpenAM’s SAML2 implementation to provide integrated SAML2 authentication to a standard OpenAM authentication chain. There are some limitations on the use of the new module - it supports HTTP-Artifact and HTTP-POST bindings and HTTP-Redirect and HTTP-POST request bindings. The new components are:
- A new SAML2 authentication module This is the authentication module that performs the bulk of the work. It handles identifying the user by sending them off to the remote identity provider, and - if appropriate - executing a sub-authentication chain which links the remote account to a local one.
- A new assertion consumer endpoint This assertion consumer endpoint differs slightly from the default OpenAM SAML2 endpoint, as it knows that it’s responsible for pushing the user agent back into the appropriate authentication chain. A SAML2 SP which utilises the authentication module must use the new assertion consumer endpoint.
- A new post authentication plugin This acts to enable IdP-initiated single logout support, and to configure and enable SP-initiated single logout.
If you’re familiar with the function of OpenAM 12’s SP implementation, the authentication module’s configuration page will be very familiar to you. The parameters filled in here can - for the most part - be thought of simply as query parameters which would be sent to the old spsssoinit endpoint. Each option is explained in terms of its function in relation to the SAML2 process both in the administrator UI and the OpenAM 13 documentation, as such they won’t be enumerated here. However, articles here will cover the options necessary to configure to be able to set up each example.
The SAML2 authentication module is a first factor module. That is, it results in the authentication modules following this module knowing the identity of the user in the local datastore the SAML2 module pointed to. This may be a newly Federated and generated user (see Dynamic Account Federation and Local Account Linking Account Federation examples) or an anonymous user (see article Anonymous Session Generation With Attribute Federation).
Finally, the SAML2 authentication module is the first module to contain the ability to perform a secondary authentication chain whose result acts as a component to this module. All this is explained in the Local Account Linking Federation example.