Hi There! I have done some more thinking, and some more implementing, and have come up with the following, lets see if you agree:
package / helper class name: I think it is ok to leave the helper class for user storage in the authenticate package. There is nothing much else in this package. The Helper class has nothing to do with security, only user storage, so Authenticate (Helper) is not a bad name, methinks. Having re-read all the docs on slide security, one can sum up: A permission is a 4-tuple (object of permission, subject of permission, action of permission, inheritable). The object is any node on the slide filesystem. The action is a slide action. The subject is currently either a node in the namespace, a role name or interface name, or a '~' self permission. The new user system allows any node conceptually to have multiple (and mutable) roles. I would propose that we rename the RoleContainer interface to 'SlideSubject'. A SlideSubject is an entity which can be the subject of a permission. In addition, we define SlideActor, a subinterface of SlideSubject, and reserved for subjects like users and groups which are associated with a real user. SlideSubject is implemented by ObjectNode and SlideRole, SlideActor by SubjectNode, GroupNode, SlideUser and SlideGroup. Incidentally, having started working in the changes to the rest of slide, it really does not look bad. After removing (!) all the stuff from namespaceconfig pertaining to roles and userpaths, there were only 12 compile errors, all of them in LockImpl and SecurityImpl. It really looks like the changes will be quite localized, with only cosmetic changes elsewhere. Richie > -----Urspr�ngliche Nachricht----- > Von: Christopher Lenz [mailto:cmlenz@;gmx.de] > Gesendet: Dienstag, 12. November 2002 11:18 > An: Slide Developers Mailing List > Betreff: Re: AW: [RootRoleImpl] > > > Michael Smith wrote: > > Christopher Lenz wrote: > > > >>Unger Richard wrote: > >> > Hi! > >> > > >> > This is exactly what I have been working on. The new > code is almost ready > >> > for CVS. > >> > > >> > Basically what I have implemented is a new Helper interface, the > >> > SlideUserDatabase, which provides an API for creating, loading, > >>saving and > >> > deleting slide users, groups and roles. > >> > >>Not very fond of the name. How about putting the helper in > the existing > >>authentification package, and, staying consistent with other helpers > >>naming, call it Authentification? > > > > > > This would be a really, really (REALLY!) bad name. The roles are NOT > > used for authentication, they're for authorization - > distinct concepts > > that must be kept seperate. > > Yeah, you're right. I just don't like the name "UserDatabase"... it > would probably generate confusion with regards to the "Store" > terminology used in Slide. > > Richard, I think it would be good if you could split your > proposal into > phases that can be attacked incrementally. For example, if the > UserDatabase is truly a "Helper", it shouldn't be necessary > to put it in > from the beginning... > > Also, if the proposal is affecting as many classes as you've > listed in > your other mail, splitting into smaller implementation phases will be > utterly necessary... as it stands you'll need a committer to > "sponsor" > your proposal, at least in the beginning. Thus, the > individual changes > must be as limited as possible. > > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > > -- > To unsubscribe, e-mail: > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:slide-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
