Now I think that we can move some more functionality in to the UM
without losing the flexibility I have mentioned earlier.
That is, we can have a USER_PERMISSION resource and all related
functionality as discussed in this thread.
In addition to that, UM can define a AUTHORIZE action, which can be
applied in resource by resource basis.
i.e. we can set
acladmin.authorizeUser("user1", "/mycollection/myresource",
UserManagerConstants.AUTHORIZE);
Then only the "user1" can perform actions which change the
authorizations on "/mycollection/myresource".
e.g. acladmin.authorizeUser("user2", "/mycollection/myresource",
UserManagerConstants.ADD) can be only performed by user1.
Thanks,
Chathura
Dimuthu Leelarathne wrote:
Hi,
Please see my comments below.
On Fri, 2007-11-23 at 10:22 +0530, Chathura C. Ekanayake wrote:
User manager (AuthorizingRealm) handles authorizations for changing
permissions using the UserManagerConstants.PERMISSION_RESOURCE.
When we set ADD permission on that resource to a user, he can change
permissions of *any* resource covered by UM.
This is a limitation when it comes to registry. I think it is better to
give "authorize" permission in resource by resource basis in the registry.
For example we might want to allow HR manager to control everything
under /departments/HR path. This includes giving permissions to employees
in the HR department. But we don't want him to mess with
/plans/super_plan path.
What we require in registry is to control all permissions details of
"resources" by the registry itself. That means we simply associate
RegistryConstants.AUTHORIZE
permission with each resource with the users who can change permissions
on that resource.
+1
But we want permission details related to "users" to be controlled by
the User Manager (e.g. changing the permissions for adding users).
So I think the solution is to add a new resource named
UserManagerConstants.USER_PERMISSION_RESOURCE. Then we should be able to set
acladmin.authorizeRole("user1",
UserManagerConstants.USER_PERMISSION_RESOURCE,
UserManagerConstants.ADD);
Then only user1 can perform operations like
acladmin.authorizeRole("user2", UserManagerConstants.USER_RESOURCE,
UserManagerConstants.ADD);
But above permission set on
UserManagerConstants.USER_PERMISSION_RESOURCE should not affect the
permissions for operations like
acladmin.authorizeRole("user3", "/departments/HR/bio1",
RegistryConstants.GET);
Let me restate the situation clearly - just thinking aloud.
Requirements are,
* We are thinking about permissions regarding users and roles, such as "changing
permission for adding users."
* The Result must be - "only user1 can perform operations like changing permission
for adding users."
* UM must not interfere when - "user3 does something with it's resources"
So the theory is,
* User add/edit/delete permissions belong to User Manager. Defined above as USER_PERMISSION_RESOURCE.
* But permission on other resources, currently defined as PERMISSION_RESOURCE
belong it's creator. (So remove it!). In this case permissions for resources
created by RegistryUser should be defined by RegistryUser.
Thanks,
Dimuthu
Thanks,
Chathura
_______________________________________________
Commons-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/commons-dev
_______________________________________________
Commons-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/commons-dev
_______________________________________________
Commons-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/commons-dev
