Re: Re: permissions managment

From: Date: Tue, 13 Aug 2002 09:13:22 +0000
Subject: Re: Re: permissions managment
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-8349@lists.php.net to get a copy of this message
Some ideas concerning the advanced Perm module: 1. naming Better distinguish authentication from authorization, instead of authentication from permission? Authentication is where you validate by comparing data (e.g. the password of a certain user; the existing Auth module), authorization is where you validate by relating data (e.g. whether an authenticated user has access to a certain ressource; the new Perm module). 2. ACLs How can we build an authorization system (the advanced Perm module) as flexible as possible? This comes down to the principle that one ressource owns another ressource. Access Control Lists (ACLs) have been proven to be highly flexible (at least to me :) in this regard. ACLs simply store the relationship/ownership of ressources in a table. 3. ressource types To be as flexible as possible, the authorization system should distinguish the type of ressource. Of course, a registered user of a Web portal is the best known kind of authorized ressource, but if we think of Web Services, a remote server can also be such a ressource, or a client GUI accessing a Web portal. A PHP script accessing a MySQL database also requires authorization. (We could also talk about 'objects' instead of 'ressources'.) 4. authorization priorities We might want to introduce priorities (maybe there's a better name for that?) of authorization. For example, a logged in user belongs to the group 'administrator' and thus he is granted access to most parts of our Website, but the super admin denied him access to a certain page. Then the user specific authorization overrules the group specific authorization. This priority scheme should again be as flexible as possible. There should be no hardcoded behaviours, instead a method should be provided to define such priority rules dynamically. 5. ressource attributes/roles We might add an attribute to the ACL which allows a more granular authorization, not only for the whole ressource, but also for parts of it. For example, a registered user is allowed to access a certain page (so far, a simple ACL is sufficient), but we will grant him access only to certain methods of this page. You could think of read/write methods or simply any method that you define on your page (e.g. modifyText(), addComment(), deleteComment(), ...). This way we can introduce roles attached to a certain ressource. For example, a user might play the role of a 'reviewer' for a certain text, then he is only allowed to write comments, but not allowed to change the text that he comments. If we think of WebServices, we attach roles to remote servers and let them only retrieve, or either manipulate the data on our server. Sandro On Dienstag, 13. August 2002 10:16, LIMBOURG Arnaud wrote: > +1 for a Perm category. Placing Perm under Auth is not good idea, imho. > > Now, offering two perm systems may prove unsufficient. A system allowing > users to create their own permission systems would be nice. Something like > what Stig did with the Pear command scheme. Now, that's just my .2EUR of > course ;) > > Arnaud. > > > The Unix permission system would fit more fort he advanced > > Perm module. > > This was the proposal for the simple system. > > > > Regards, > > Lukas -- Sandro Zic oc4ware Project Manager oc4ware - Software 4 Open Communities http://www.oc4ware.org oc4 e.V. - Association of Open Communities http://www.oc4home.org

« previous php.pear.dev (#8349) next »