directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Commented: (DIREVE-68) Authorization Service: hardcode simple authorization rules for safty
Date Mon, 01 Nov 2004 08:10:33 GMT
     [ ]
Alex Karasulu commented on DIREVE-68:

Added protection against changes and deletes in the following revision:

We still need to have a policy for dealing with search, list and lookup.  I'm thinking the
best approach is to not return anything at all for anyone except the admin user.  Other users
besides the admin should not even know about the existance of these user accounts.

> Authorization Service: hardcode simple authorization rules for safty
> --------------------------------------------------------------------
>          Key: DIREVE-68
>          URL:
>      Project: Directory Eve
>         Type: Task
>   Components: interceptors
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu

> We need to prevent everyone except the admin user from accessing the admin user's entry.
 It should not be returned on searches and lookup's should fail if these operations are not
being conducted by the admin.  This will prevent other users from being able to read the admin's
entry or alter it.  In general I'm not in favor of hard coding rules but this is one that
is almost universally valid and is ok to hardcode.  After all this can be changed later as
dynamic authorization policy mechanisms are put into place.  Also modifyRdn and delete operations
will not be allowed!
> Furthermore we can extend this to regular users where only those that own their entry
under ou=users,ou=system can read, or modify their entry.  No modifyRdn, or delete operations
are allowed on these entries by any user except the admin user.  The admin user can do anything
it wants to do.  Other users besides the creator/owner cannot read the userPassword field.
> This is basically a new interceptor implementation.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message