Re: Re: permissions managment
| From: | Sandro Zic | 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