As a mostly passive observer of the Slide project (with only a few posts and patches), may I offer my two cents worth.
First, I want to thank you for taking on this piece of Slide, it is sorely needed in my opinion. However, Authenticate is a poor choice for the helper name. It clearly conveys a function that is not in line with your library's. Authenticate suggests a process by which a principal's identity is verified as to whether he/she/it should be granted access. This helper library is for the management of users, groups, and roles. Seemingly not the same thing. How about RealmHelper, where Realm suggests the concept of users and groups. There is a chance this would cause confusion with the infamous SlideRealm but they are at least in the same conceptual area. Hope this helps. Michael > 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> > -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
