Table of Contents

Single Sign On

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 state for the relevant authenticator within the  SSO Group.

SSO Properties

An SSO state that gets saved when a protocol agnostic authenticator is executed successfully (and has "setSSOParameters": "true") will persist 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

Multiple SSO states can be active at the same time (but just one state per authenticator) 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 an SSO State exists for this authenticator id. This means you are only allowed to skip an authenticator you have previously executed successfully. The resulting item from the previous authentication will be used to construct the response. This also means that SSO-enabled authenticators should not rely on in-data that can vary based on the login context (if it does, it should be directed elsewhere with a Dispatch), as the SSO state will just pick the same item as from the initial authentication, and proceed from there.

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. See the example of how to configure step-up authentication for more details: Step-up authentication

Customizing your SSO behavior

You may have use cases where you need slightly different SSO behavior, for example if you want to direct your authentication flow based on properties from an initial authentication, you can use Meta Attributes. Meta attributes will allow you to set some attributes upon successful execution of an authenticator, which you can then use later in subsequent authentication flows.

For example, you may want to create a step-up flow where previously authenticated users of different roles are directed to different step-up authenticators. This can easily be achieved by setting a meta attribute for that role, and using a Dispatcher to direct the flow.

Authentication Single Sign-On