About

SAML authenticators allow for PAS to act as a SAML service provider, SAML Identity provider or a SAML broker.  Brokering can be between SAML IPD's and SP's or even across protocols, internal to SAML, OIDC to SAML or vice versa.

As a SAML IDP

When acting as a SAML IDP PAS will handle both solicited and unsolicited SAML flows. Whether to a allow unsolicited requests is completely configurable. 

A typical SAML flow starts with the identification of a user, (this can be done in a number of ways). After a successful authentication, the IDP will create a SAML  assertion based on the configuration.  

The creation of the SAML assertion is highly configurable to ensure a good fit in all SAML federations.     

As a SAML SP

In scenarios where an IDP is already in place, it may be a good idea using that IDP when accessing internal resources such config or activation portals. 

A SAML service provider authenticator allows for consumption of SAML assertions to grant access to internal resources. 

As a SAML broker

Typical use case is when "hiding" multiple IDPs/SPs  or translating between SAML dialects or even between other protocols like OpenID connect and SAML

Common configuration

When configuring a SAML authenticator there are a couple of configuration parameters that are common to all authenticators. These are described here and not for each authenticator.

translation

For those authenticators presenting UI, this parameter allows customers to add custom translation not in the default template.

"translation":["custom.translation1","custom.translation1"]

In order for this to work the translation keys must be added to the translation files.

sessionValues

Used to populate data from the session to UI templates. This could be name, email etc.

"sessionValues":["mail","mobile"]

The key names in the sessionValues will be fetched from the session and replaced by their value.

allowLanguageChange

For authenticators providing UI, this option allows user changing language.

"allowLanguageChange":"true"

attributesFromRequest

When receiving a SAML request there are cases when additional data from the request needs to be saved. This can be done by configuring the authenticator using "attributesFromRequest". Then configured values will be stored in the current session. Replacing any existing values with the same name. 

"attributesFromRequest":"email,givenname"

Note that the values will only be stored if the incoming request contains a valid saml request and relay state.

Configured values are case sensitive

success_template

When saml POST binding is used it is possible to set a custom auto post template. Default value is autopost.template


Change by setting:

"success_template":"<the_template>

forceReauthenticate

When an already authenticated session exists, some authenticators automatically picks up the userID etc from the authenticated session.

To always perform full authentication, even when a authenticated session exists, this configuration param must be set to true. Default is false.

Change by setting:

"forceReauthenticate":"true"