AW: AW: [SlideRoles!] naming issues

[Unger Richard <ru...@camino.at>]

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:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>