Single sign on for Protocol Agnostic Authenticators

Single sign on is very easy to enable when using protocol agnostic authenticators. If the SAML IDP or OIDC OP you are trying to authenticate with has "allowSSO": "true" in their configuration, requests will automatically attempt Single sign on (SSO). 

The way it works is completely opt-in for each authenticator. Each protocol agnostic authenticator has a configuration property called "setSSOParameters", which - if true- will set the SSO properties for the relevant SSO Group. 

SSO Properties

SSO properties that get saved when a protocol agnostic authenticator is executed successfully (and has "setSSOParameters": "true") will save the following properties

  • The resulting item from the authenticator pipe (if any)
    • AgnosticAuthSelector and AgnosticDispatcher are special here -- they will save the resulting item from the chosen / routed to-authenticator
  • The resulting user ID from the authentication
  • The authenticator ID responsible for the authentication
    • AgnosticDispatcher is special here -- It will save the ID of the authenticator that the dispatcher routed the request to

Only one set of SSO properties can be active at the same time for each SSO Group (explained below). 

SSO Flow & Criteria

When a request attempts SSO (set by "allowSSO" property at IDP / OP as described in the first paragraph), it will be treated as a normal authentication request until it lands at a protocol agnostic authenticator (AgnosticDispatcher will just route the request forward as usual). At this point, SSO will be allowed if the request is for the same SSO Group as previously, and authenticator ID is identical to the authenticator ID saved as an SSO property for the SSO Group. This means you are only allowed to skip the authenticator you have previously executed successfully. The resulting item from the previous authentication will be used to construct the response. 


SSO Groups

SSO Groups allow an authentication session to be shared between entities. An entity in this context means a unique combination of protocol (SAML or OpenID Connect) and id (IdP ID or OP ID). By default, each entity is its own SSO Group. You can configure your SAML IdP or OIDC OP to belong to a specific SSO Group simply by adding the configuration parameter "ssoGroupId": "myvalue". 

The purpose of this is to allow both SAML and OIDC authentication for the same authority. You simply configure your OIDC OP and SAML IdP to use the same authenticatorId and belong to the same SSO Group, and you can log into OIDC and then SSO into SAML, or vice versa. It is not recommended to add several entities of the same protocol into the same SSO Group, but it is possible.

SSO-enabled authenticators within a sequence

You may have SSO-enabled authenticators that you want to use within a sequence (e.g. for step-up authentication). For clarification on what a "sequence" is -- check the documentation for SequenceAuthenticator, also new in PAS 5.1. If you have an example sequence as such: 

  1. DynamicAuthenticator (username & password) -- SSO ENABLED (setSSOParameters: true)
  2. AssignmentAuthenticator

Then executing the sequence will (if you have previously authenticated that particular authenticator successfully at this entity) SSO past the first step, and only perform the second step. This allows for powerful and easy-to-configure step-up authentication. A detailed document with an example of how to configure step-up authentication exists within the solution directory.