SAML Identity Provider in PAS 5.1 and beyond

The introduction of protocol agnostic authenticators also includes new updates to SAML Identity Providers in PAS 5.1. Old configurations will still work, but not have access to these new features.

Things that previously required additional configuration is now available straight out the box, including the following: 

  • SAML Logout / SLO
  • SAML SignMessage display

To get started, simply follow the "SAML Identity Provider" guide scenario in the configuration manager, under the "Federation" tab. There, you will input the base URL of your PAS server, the internal IDP ID, and some more minor configuration to get your identity provider going. The resulting configuration based on your base URL and internal ID will be the following: 

  • Entity ID: <base-url>/authentication/saml/<internal-idp-id>
  • postSSOURL / redirectSSOURL: <base-url>/authentication/saml/<internal-idp-id>/login
  • postSLOURL / redirectSLOURL: <base-url>/authentication/saml/<internal-idp-id>/logout
  • Metadata endpoint: <base-url>/authentication/saml/<internal-idp-id>/meta

You will also choose an authenticator that will be executed at the login endpoint. This is usually an AgnosticDispatcher or AgnosticAuthSelector that can direct the flows further, depening on your needs. New SAML Identity Providers also come with a pipe that executes an AssertionProvider, with the execution condition that no other Assertion has been provided previously in the flow. If the configuration for your AssertionProviders do not depend on the authenticator flow, you can simply configure this to fit your needs. You can also place AssertionProviders in the pipes of the executed authenticators if you wish. The pipe run by the identity provider will have access to the same item from the pipe of the authenticators, so you do not need to populate the item from scratch.

In the new SAML Identity providers, there is no need to resolve SAML request properties like in PAS 4.7 for authenticator flow direction, this is done automatically once per AuthnRequest. It is then loaded into the "context"-property that is available at the AgnosticDispatcher. If a SAML AuthnRequest contains a SignMessage, it is always displayed before proceeding to authentication. AssertionProviders will, if the request contains a SignMessage, add a SignMessageDigest attribute. The "comparePrincipal" property at an AssertionProvider still works as before, even without "resolveSAMLRequestProperties" being set anywhere. 

These are new configuration properties for SAML Identity providers: 

  • strictValidation -- A set of additional validation checks run on incoming SAML AuthnRequests. In the old identity providers, this option was set at authenticator level. 
  • sendSAMLResponseOnError -- If fatal errors should result in a SAMLResponse containing the error status.  In the old identity providers, this option was set at authenticator level.
  • autopostTemplate -- Configurable custom autopost template. In the old identity providers, this option was set at authenticator level.
  • allowUnsolicited -- Whether or not to allow unsolicited requests. 
  • authenticatorId -- The ID or alias of the authenticator to execute at the login endpoint
  • allowSSO -- whether or not SSO should be attempted at this identity provider. Read more about SSO in protocol agnostic authenticators before proceeding.
  • pipeId -- the id of the default assertion provider pipe

If you wish to set up a SAML holder-of-key flow, you may do so using the "hokCertificate" parameter for AssertionProvider. At the identity provider, you should include a configuration parameter called "postSSOURLHoK" (and/or "redirectSSOURLHoK") and it should have the value  <base-url>/authentication/saml/<internal-idp-id>/login/hok. You can then direct the authentication flow via AgnosticDispatcher and "context.bindingIsHok".