IdP Authentication and Sessions

Authentication

The IdP uses software components called LoginHandlers to authenticate users. Each LoginHandler is responsible for performing one or more types of authentication. For example, there might be authentication processes that validate a username/password against an LDAP directory, validate an X.509 certificate, or check a one-time-password. Each LoginHandler has associated with it an authentication method duration. The duration identifies the amount of time, after initial authentication, that this method may be used to automatically sign on a user (i.e., SSO) to the service. Once that time passes, the user must authenticate again in order to use that particular authentication method.

User Session

The user session tracks information about the user (e.g., what authentication methods are currently active, which services has the user authenticated to, etc.). This information is used by the IdP to determine whether SSO should take place, which services should receive logout requests (once the IdP supports SLO), and so forth, and may be used within the attribute resolver and the attribute filtering process. A session also has an inactivity timeout that is reset any time the user is authenticated to a service provider.

Relationship between Authentication Method and Session

The relationship between authentication method duration and session lifetime can be confusing. The session controls the overall lifetime of the user's interaction with the IdP. That is, if the session is terminated (e.g., because it timed out) the authentication method duration is irrelevant. All methods are terminated with the session.

Here's an example. The IdP has configured a session lifetime of 8 hours (up from the default of 30 minutes). It has two LoginHandlers configured. One performs username/password (UP) authentication and has a duration of 1 hour. The other performs X.509 authentication and has a duration of 15 minutes. The user logs in to SP1 and authenticates to the IdP via the UP LoginHandler. The user then logs in to SP2 and authenticates via the X.509 LoginHandler. The user goes for tea and comes back in 20 minutes.

Next the user tries to log in to SP4, which happens to require X.509 authentication. The user is asked to re-authenticate because the authentication method duration has passed (it was only 15 mins) for that LoginHandler. Then the user logs in to SP5, which requires UP authentication. In this case, the user is not prompted to re-authenticate because the authentication duration has not passed for this authentication method.

Now assume that the UP login method has a 10 hour authentication duration. The user goes to SP1, logs in with UP authentication, and then goes to bed and sleeps a full 9 hours. After the user wakes up, he goes to SP5, which requires UP authentication, and is asked to re-authenticate. In this case, re-authentication occurs not because the authentication method duration has passed but because the session was terminated due to inactivity, and therefore all authentication methods have been terminated.

Browser not supported