FW: [dev] Single Sign-On

[Thomas Fichtenbauer]

> It is for backends suth as Auth_ipbasic and Auth_http that use 
> existing authentication to transparently log a user on to Horde. 

Great work - this is very close to what I implemented yesterday. 
If I had seen your new Auth.php I would have saved 5 days 
of work (my fault). However, good to be confirmed that you think 
very similar. I had doubts if you would ever accept changes in 
Auth.php since it is a very basic script.

But there is still a feature missing I need for our 
implementation: the timeout. The current Auth::getAuth() is:

    function getAuth()
    {
        if (array_key_exists('__auth', $_SESSION)) {
            if (!empty($_SESSION['__auth']['authenticated']) &&
                !empty($_SESSION['__auth']['userID'])) {
                return $_SESSION['__auth']['userID'];
            }
        }

        // Try transparent authentication now.
        global $conf;
        $auth = &Auth::singleton($conf['auth']['driver']);
        if ($auth->hasCapability('transparent') &&
            $auth->transparent()) {
            return $_SESSION['__auth']['userID'];
        }

        return false;
    }

This is good for a one-time logon. So for example: if the user
is logged into System A and now changes to Horde, then Horde will
check for $auth->transparent() (assuming the appropriate Auth-
extension is set) to log into Horde the first time. From now on 
each call to Auth::getAuth() is answered using the session 
variables without touching the extension.

The problem is: we have a timeout for the session maintained in 
the leading non-Horde (Java) application (set to 30 minutes, but 
this is not important). So if our visitor is using Horde for more
than 30 minutes and then calls a page of the Java application 
she/he will be redirected to the login screen.
 
The way I have solved it is to use another call to the 
authentication instance to check for a Horde-validation-timeout 
each time Auth::getAuth() is called. This opens a way to touch
the Java-session periodically (think of 5 minutes or so) 
and that way keep the timeout there up to date.

To follow up on the code-example above this would look 
something like:


    function getAuth()
    {
        $auth = /* create auth instance here */

        if (array_key_exists('__auth', $_SESSION) $$ 
			!$auth->checkTimeout()) {
            if (!empty($_SESSION['__auth']['authenticated']) &&
                !empty($_SESSION['__auth']['userID'])) {
                return $_SESSION['__auth']['userID'];
            }
        }

        // Try transparent authentication now.
        if ($auth->transparent()) {
            return $_SESSION['__auth']['userID'];
        }

        return false;
    }

Something like this is good for an application where 
transparent authentication is used *all the time*. But I would 
not accept it into the main source tree: too error-prone for
most users.

I would suggest something like:

    function getAuth()
    {
        global $conf;
        $auth = &Auth::singleton($conf['auth']['driver']);
        if ($auth->hasCapability('transparent') { 
		$auth->getAuth();
        }

        if (array_key_exists('__auth', $_SESSION)) {
            if (!empty($_SESSION['__auth']['authenticated']) &&
                !empty($_SESSION['__auth']['userID'])) {
                return $_SESSION['__auth']['userID'];
            }
        }

        return false;
    }

This way the auth-extension is free to handle all the checks 
needed, including the timeout issues. And the code in Auth.php
is simple enough for all the others not to make mistakes.

What do you think? Would you accept such a change?

thomas
thomas.fichtenbauer@mamilade.at


-----Original Message-----
From: dev-bounces@lists.horde.org [mailto:dev-bounces@lists.horde.org]On
Behalf Of Chuck Hagenbuch
Sent: Samstag, 16. November 2002 18:00
To: dev@lists.horde.org
Subject: Re: [dev] Single Sign-On


Quoting Thomas Fichtenbauer <thomas.fichtenbauer@mamilade.at>:

> My question: there is a parameter called 'transparent' in the Auth.php
> $capabilities array. What was the intended use of it?

It is for backends suth as Auth_ipbasic and Auth_http that use existing
authentication to transparently log a user on to Horde. See those two for
examples.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"People ask me all the time what it will be like living without otters."
 - Google, thanks to Harpers

-- 
Horde developers mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@lists.horde.org