Login process

From DOC

If we were to enable the Access Logger, it would look something like this:

127.0.0.1 - - [11/Feb/2009:13:26:48 -0800] "GET /Tolven/ HTTP/1.1" 200 397
127.0.0.1 - - [11/Feb/2009:13:26:48 -0800] "GET /Tolven/private/dispatch.jsf HTTP/1.1" 302 -
127.0.0.1 - - [11/Feb/2009:13:26:50 -0800] "GET /Tolven/private/dispatch.jsf HTTP/1.1" 200 7058
127.0.0.1 - - [11/Feb/2009:13:27:00 -0800] "POST /Tolven/private/j_security_check HTTP/1.1" 302 -
127.0.0.1 - bob [11/Feb/2009:13:27:00 -0800] "GET /Tolven/private/dispatch.jsf HTTP/1.1" 302 -
127.0.0.1 - bob [11/Feb/2009:13:27:03 -0800] "GET /Tolven/vestibule/selectAccount.jsf HTTP/1.1" 200 21698

This log reveals the part of the Login process that shows how Tomcat intercepts a normal page request in order to request the username and password. There are three redirects:

• The first redirect (first line with status 200) is from the welcome page as defined in web.xml.
• The second redirect is caused because the target page is a "protected" page as defined in web.xml.
• The third redirect is cause by the Tolven GeneralSecurityFilter which requires that the user must select which Account to log into.

With this page-flow in mind, we can look a bit deeper into the flow in a Tolven web application:

1. A very early step in the process of handling a browser HTTP request is to determine if the requested URL is protected according to the patterns defined in web.xml.
2. If the requested page is protected, but the "principal" has not yet been established, then the login process must intervene.

Establishing the principal is sufficient in most applications. But Tolven also needs to decrypt the user's private key and store it in memory for use in decrypting and signing documents. This process is handled by a JAAS login module called KeyLoginModule. This login module is configured in the server/tolven/conf/login-config.xml file. JAAS allows additional login modules to participate in the login process as well. In fact, this is typically where third-party security managers intercept the login process (if they want to do it in a standard way).

Tolven provides security around both the web tier and the "ejb" tier. Even though these two tiers typically exist in the same virtual memory space, their security context is managed differently. Therefore, when the user is authenticated on the web side, the security context must also be established on the ejb side. In fact, most methods in the tolvenEJB not only require the user (principal) to be authenticated in the so-called tolvenLDAP security domain, the user must have certain roles.

In order to avoid having to re-check credentials for every page, a cache is used to remember the principal and security context from page-to-page for a session. This cache allows for session migrations. For example, even though a given request is constrained to a single thread while it is being processed, the next request from the same browser and same session could end up with another thread.