Re: New Package Proposal: Enterprise A&A

On Tue, 14 Jan 2003 14:25:12 -0600 (CST) Tony Bibbs <tony@tonybibbs.com> wrote: > Yeah I saw live user. There are some similar concepts and you have the > benefit of at least a couple of additional heads. I didn't see a > convenient link to CVS for it on the PEAR site so without seeing some of > the code, it doesn't sound like it was designed to be exposed as a web > service. Is that right? It was designed with web services in mind, but none of us had the time and/or experience with web services to implement an appropriate driver. Basically, the concept allows for complete independence of the data storage - this can be a web service, a database, an LDAP server, a .htpasswd file .... to be continued. Everything depends on the driver classes, the end user will always have the same API. > Regarding implied rights, the A&A system makes no assumptions about how > permissions are used. It is up to the application to design appriopriate > permissions as needed. That, IMHO, offers the greatest level of > flexibility. All I do is get the groups a user belongs to any rights > those groups may have and any rights tied directly to the user. How those > rights are used is up to the application. Here LiveUser is a little bit different: The authentication component will _only_ do authentication. This means, it checks if the requested user exists at all, if his password is matching and if he has been declared "valid". Additionally, the database driver that comes with the package logs the time of the last login. LiveUser´s LoginManager class (the only class the end user actually deals with) can be configured so that, if a user could not be found in one container, other containers are being tried. This is useful in situations where you have i.e. a corporate extranet with its own user database where customers can apply for user accounts. Additionally, the company´s employees have to be able to access the extranet as well. The employees´ user accounts already exist in the company´s LDAP server and should not be recreated. Therefore, the login process is configured so that first the extranet´s own database is queried, and if a user can not be found there, the LoginManager will query the LDAP server. The permission container is completely separated from the authentication container and can run against a completely different type of storage device (or a web service). Two permission containers are currently included in the package which provide application developers with the most needed features. However, every application developer is free to write his own container if the existing containers won´t match his demands. The permission containers take care of managing group membership, access rights, authentication areas and more, depending on the container. As all containers inherit from a common base class, it´s easy to maintain the same API even for containers with different feature sets - if a feature is not supported, a PEAR_Error object will be returned whose error code indicates that the method is not supported. Easy downgrading is possible. Regards, Markus -- Markus Wolff <wolff@21st.de>