Re: Anybody working on SSO class/project ???
| From: | Tomas V.V.Cox | Date: | Sat, 01 Jun 2002 17:32:10 +0000 |
| Subject: | Re: Anybody working on SSO class/project ??? | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-6699@lists.php.net to get a copy of this message | ||
Nicolas Hoizey wrote:
>
> Hi everybody,
>
> I'm currently trying to design a PHP SSO (Single Sign On) application,
> and would like to know if anybody has already done anything.
>
> I haven't found any SSO project in PHP yet, but I think it should be
> part of the Auth package. Some people tried to design a User class a
> while ago, but I don't know if it has given anything.
I don't think it should be part of Auth, I'd say to use it as part of
the "User" thing.
> The simple way would be to patch all application so that they use the
> same auth application, but it would break compatibility with those
> application updates.
I can think on a pluggable architecture where each application provides
a file with common functions like: addUser(), removeUser(), etc. From
the central user admin, a call to the main addUser() function could call
all the app specific addUser() funcs.
I guess that this solution is not a real SSO system, it's more a
"uniform way for handling users" but gives a solution to the "disspersed
auth systems" problem. Each application needs too specific data and I
finally get to the point where is really difficult (for not saying
imposible) to have a unique "container" of user data.
Then, if an app would like to support our SSO, they would only have to
code that file and put some methods at the top of their code (more or
less the ones Auth provides).
> The best way is then to provide an application that stands on top of
> all others, and give the ability to use one single authentication to
> access to those others. It needs to know how each application performs
> auth and "simulate" it for any user.
>
It's easy to put an auth layer on top the applications, but if it is not
integrated inside the application will be useless: "oh yeah you can
access the CMS part, but you are not registered there" :-)
We could also provide some helper functionality like: ACL managment,
time-controlled sessions, log user accesses, etc.
I'm actually very interested in such system. For a private project I
fell into the problem of having to integrate 4 very different
applications into a main one, dreaming a lot on a SSO system which could
avoid the dumb hours I spent on the work.
For being successful in that project, I guess we should invest a lot of
time on documenting an doing a big "marketing" job promoting the use of
it. I'd talk with the main developers of the current more used
applications (let's say phpnuke, phpBB, phorum, postnuke, agora, XXX) to
exchange needs and ideas, and of course to sponsor/support the proyect.
By the way for being as neutral as possible I'd call it "PHP User".
Tomas V.V.Cox