[dev] Single Sign-On

Thomas Fichtenbauer thomas.fichtenbauer@mamilade.at
Tue Nov 19 04:57:52 2002


Quoting Chuck Hagenbach <chuck@horde.org>:
> Unless a bunch of other people speak up needing this, 
> I'd rather it stayed a local modification for you.

There is another way to get around the timeout issue 
without changing the Auth:getAuth(). This requires 
transparent login on the non-Horde system however: 

For example: 

           +----------------------+
           | users Browser        |
           | cookie: AAA          |
           | cookie: BBB          |
           +--|----------------|--+
              |                |
              |                |
             \|/              \|/
 +------------'------+     +---'---------------+
 | Application A     |     | Application B     |
 | using cookie AAA  |     | using cookie BBB  |
 +----------------|--+     +--|----------------+
                  |           |
             .----|-----------|----.
            /  common user db       \
            \  (eg LDAP)            /
             `---------------------'
            
             

Consider the setup above: two applications A and B. Each 
application is using it's own cookie to maintain it's own session. 
Since both applications work in the same domain (and provided the 
cookie-path is set properly) the browser sends both cookies 
to both applications.

Now our user logs into application A (which could be a 
non-Horde-application for example). In the next step the user 
requests a page from application B (think of Horde here). 
Username and password are then transparently passed as 
described earlier in this tread. 

Now let us assume that the user works entirely with application B 
not touching app A. So at some time the session at app A is 
destroyed and the user still works happily with application B.

Now the user returns to application A. Here comes the point: 
application A can just as well validate cookie B using the 
same transparent login technology. 

This means more flexibility: the user can logon to whatever 
system she/he chooses - the other system (mutual trusting 
each other) will take over the login data. However: it also 
requires to implement transparent login on both sides.

thomas


More information about the dev mailing list