Configuring User Authentication
In order to support SAML 2 authentication request features like passive and forced authentication and authentication contexts, the IdP must do some amount of processing prior to invoking whatever mechanism(s) are in place to authenticate users. This is different than previous versions of Shibboleth where the user was authenticated prior to the request reaching the IdP.
Before proceeding it would be beneficial to understand the relationship between authentication methods and the user's session.
Define the Login Handler
Each authentication mechanism is configured differently, as each has different requirements. The following authentication methods are supported:
Mechanism |
Description |
|---|---|
Sets the principal name in the IdP to |
|
Login handler that delegates to another authentication system to perform the actual user authentication and identification. |
|
Presents the user with an authentication page and then checks the entered username and password against an LDAP directory or Kerberos 5 domain. |
|
Checks the user's IP address against a given range to identify the user as a pre-determined principal. |
|
Called when the user's existing session is used as the authentication mechanism (i.e., when the IdP is performing an SSO-based sign-on.) |
Authentication Method Selection
The IdP supports the use of multiple authentication methods at one time. When using SAML 2.0, a service provider may require one of numerous authentication methods be used by supplying a list of acceptable methods in its request. In SAML terms, these methods are expressed as <AuthnContextClassRef> elements.
If the IdP is configured for one or more of the methods requested by the SP, then that method may be used. If the Service Provider does not specify a particular method, and the user does not have an existing session, then the default method, identified on the relying party's configuration, is used. If no default is specified, the IdP chooses a method randomly.
If the user has an existing session, and that session indicates that there is an active authentication method that meets the SP's requirements, then the PreviousSession login handler is used if it is configured. This is what gives Shibboleth its SSO support. If the SP does not request a particular method in its request, note that the default method in the configuration is NOT consulted when determining whether to honor active methods. In this case, any active method can be used to satisfy the request.
If an active authentication method does not meet an RP's explicit requirements, then the user will be prompted to authenticate again using a method required by the RP. This can happen unintentionally if, for example, RP1 has a specific relying party configuration specifying a method that maps to UsernamePassword, while RP2 uses the default relying party configuration that does not specify a method and ends up using the "unspecified" method handler. The access sequence of RP1 followed by RP2 will not require reauthentication since RP2 doesn't care what authentication method is used. However, the sequence of RP2 followed by RP1 will require reauthentication since RP1 wants UsernamePassword while "unspecified" was used before.
To be a bit more specific here, in this case, Shibboleth will pass in the authentication method as "unspecified". If the login handler in place does not change that value, then Shibboleth will record that method in the session. If the login handler in use updates the method to reflect a different method, then that method will be recorded in the session. So, the overall behavior is dependent not only on the Shibboleth configuration used, but on the login handler used.
Session Lifetime
The session lifetime is configured in the IDP_HOME/conf/internal.xml file. Locate the shibboleth.SessionManager bean. Its second constructor argument is the inactivity timeout, in milliseconds, for the session. By default it is 30 minutes.
Admittedly, this is a totally confusing and poorly represented setting. It will be changed in a future release.