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.     

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. 

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

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.

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.

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.

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

"allowLanguageChange":"true"

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>"