> >> Details were in short supply in that original email, agreed. > >> I'm a little confused why the traditional roles or group membership > >> model won't work here? I can see the need to create an aux or even > >> structural objectclass for the application information, but assigning > >> rights should be a snap and could use what is already there. > >> Or am I missing something? > > Ditto, the above. And with the advantage that most [all?] LDAP tools > > understand groupOfNames and provide some support for group management > Thanks for your help all. I guess I'm the one who is missing something ;-) > The pdf in the link from Dieter earlier was helpful, because I did not > know about the "traditional roles or group membership model". > I'll describe what the project is about: we are building a portal > (hippo-portal, based on jetspeed) where there will be all kind of > portlets on the pages. You have to authenticate first (ldap). Which > portlets somebody can see, or what they can do in the porlet (read-only, > read/write for example) is depended on who you are.
We have much the same thing with the sites we use; access is based on group membership. We authenticate the user and then query all the groups the user is a member of, and then we cache that list in the session. What objects the user can see/manipulate is tied to group membership. > I'm experimenting with the groupOfNames below my Module container, and > it looks like I can skip some of my custom classes with that.
