...
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> or <AuthnContextDeclRef> 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 the SP requests more than one possible matching class or declaration to use, then (assuming the PreviousSession handler is enabled for SSO), the IdP will check for 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 usedmethod in the user's session that satisfies one of the requested values and will use that if possible. Otherwise it will select a matching handler to use for authentication.
A note about the built-in handlers: for security reasons, the handlers are configured to cross-check that the method they supply to the user's session matches the method that an SP asked for. This results in a limitation for the built-in handlers such that they support only a single method type in a given configuration, rather than allowing for more than one at a time. A custom login handler can circumvent this limitation by supporting multiple methods at the same time (even if those methods are really just different ways of expressing the same underlying behavior by the handler). This is important for scenarios in which different SPs are expressing or expecting different values for the same underlying mechanism.
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.
...