Horde – Single Sign-On

Summary

This Document is a brief description of the Single-Sign-On architecture for the Horde Project. It describes the technical background of the logon process.

The two components used are the leading application, which we will call simply "application A" in this document, and the Horde/IMP webmail-client (Horde Project, www.horde.org, written in PHP). The user is using the logon-process provided by application A. Horde is using a simple service provided by application A to validate the user request.

Architcture

The main components in this chart are:

leading application A (based on Java and JSP)

Horde/IMP web-mail client based on PHP (www.horde.org)

The LDAP directory

The IMAP-mailserver

Basic functionality

Step A:

The first thing a user does is to login at application A. If the user is pointing his browser to a page hosted at Horde side, Horde will redirect this request to the login-page of application A.

As soon as the user connects application A a session bean is created.

During the login dialog the user is asked to provide username and password.

Application A checks user name and password against the values stored in the LDAP directory.

If user name and password are valid the session is updated accordingly.

By the end of step A the session bean lives on application A. The customer’s browser has stored the session cookie coming from application A. Beside from redirecting the user to application A’s login page Horde is not involved in creating the session at application A.

Step B:

The user is accessing his/her mail box for the first time. Along with this request the user’s browser sends A's cookie to Horde.

Step C

Horde is checking it's own session variables for a valid user. If there is no loged User, the authentication driver of Horde asks application A to verify it. This is done by a simple HTTP GET request from Horde to application A. This request sends the AAA cookie in the same way the browser would send a request to application A (this is similar to what we call “session high-checking”). On application A a simple JSP-script is using the existing session bean to verify the session. Since the AAA-Cookie is presented in a way the browser would send it, there is very little extra programming necessary on the application A side to verify this session. The servlet container provides the appropriate session bean. The default behaviour of the session bean is used to check if the user is loged in.

In response to the validation request application A sends the user’s DN (Distinguished Name) if the session is valid, or a defined string if it is not. The DN will be used by Horde to retrieve the user settings (see next step).

Step D

Horde is using the DN to get user settings from LDAP

Horde is caching the LDAP data locally in its session parameters

Horde/IMP connects to IMAP mail server

Horde is setting its own session-cookie to maintain its session: in the chart above represented as cookie DDD.

Horde/IMP sends the response to the customers browser

From step D on Horde/IMP and application A are maintaining their own session. The Horde session timeout is a little shorter that the Application A session-timeout (eg. 30 min for session timeout at application A, 25 min for session-validation-timeout in Horde). This ensures that the session can’t be closed due to inactivity on the application A side. If a user works longer than the Horde -validation-timeout entirely with Horde, Horde will revalidate the session with another HTTP-verify request. This way the session at application A is again touched and activated.

If a session is timed-out the user is redirected to the login page.

Logout

Logout page is located at application A again. During logout the following 3 steps are done:

Application A sends a HTTP request to Horde to notify that the session ends

Upon receiving the session-end-request Horde closes the associated connection to the IMAP server and destroys it’s session

Application A destroy the session bean at application A side

The first step is a simple HTTP-request from application A to IMP. This is similar to the step C during building the IMP session, but the other way around: this time application A is sending the request using Horde cookie (cookie DDD in the chard above). Horde is taking this cookie to destroy the session at Horde side.

Requirements

To login the browser must have cookies enabled

The cookies set by one application must be readable for the other application

Customer’s
Browser
Cookie AAA
Cookie DDD

Internet

privat LAN

Application A

Horde/IMP

Web-Server

LDAP

Step A: login

Step B: mailbox access

Step C: HTTP-Request
to validate Cookie AAA

Response: validation

Step D: get user
settings from LDAP

Step D: set Cookie DDD and
sow mailbox content

IMAP mailserver

Step D: connect to IMAP server

Simobil – Single Sign-On

Thomas Fichtenbauer

2002-11-14

UNISYS