Hi, Is this a required feature for UserManager 1.0 ?
Thank you, Dimuthu On Mon, 2007-11-26 at 23:35 -0500, Glen Daniels wrote: > Hi Dimuthu, all: > > > Should I go ahead with the second suggestion? > > +1 from me, but I think we need to make sure that we all agree about the > supported use-cases. For example... > > / : read(everyone), write(admins) > /foo/ : no specific ACL > /foo/bar : no specific ACL > > In this situation, the admins group will be able to write to foo and bar > by default. Let's say joe is in the admins group. He can PUT /foo/bar. > If someone removes the write(admins) permission from the root, Joe > will no longer be able to do so. > > I think this seems reasonable. Do others agree? Is this approach, > where permissions are inherited from parents if no specific permission > is found, the correct one? > > > If we are going ahead with the second approach I see couple of > > implementation methods. > > > > * Change the Authorizer interfaces to accept the hierarchyManager as shown > > by Glen. > > myAuthorizer.isUserAuthorized(resource, action, user, hierarchyManager); > > > > * Create a Authorizer giving the hierarchyManager callback and leave all > > method signatures as it is. > > Authorizer myAuthorizer = null > > > > if(hierarchymanager!=null) > > myAuthorizer = new Authorizer(HierarchyManager hierarchymanager); > > else > > myAuthorizer = new Authorizer(); > > Right - the question is whether or not a given Authorizer will have one > and only one HierarchyManager. This seems logical to me, but it brings > up the issue of how a single UserManager gets shared among several > instances of our products - or does that even make sense? Maybe the > only part that gets shared (via an LDAP store, for instance) is the > Authenticator and the storage for users and roles. So then each > instance of the Registry would have its own UserManager with its own set > of permissions and hierarchy.... If that's the case, +1 for the second > implementation method. > > Thanks, > --Glen _______________________________________________ Commons-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/commons-dev
