Hi, Could someone please point me to the proposal being refered to ?
I would have assumed that the capabilities of a user are associated with the principal rather than the subject. A prime example would be one in which a Subject may play the role of an Admin and some other non Admin role. Typically a principal may not play both roles, however a Subject may. Thanks. - viraf --- James Taylor <[EMAIL PROTECTED]> wrote: > > I have finally understood Eric's proposal > regarding Subjects and > > Principals. A Subject (a user) can be known by > many names (Principals), > > such as Joe, uid=42, whatever; each name is > associated with a set of > > permissions; it doesn't make any sense to ask what > a Subject's set of > > permissions is; it makes sense to ask what a > Subject's Principal's > > set of permissions is. Is that a correct > understanding? Now, could > > anybody show a real-life example of the use of > this? Because I would > > have thought that, no matter how a Subject is > known, the permissions > > for that Subject should be the same. > > I agree, and still feel that if we offer a default > implementation of > authorization it should map permissions to subjects > (possible via roles) > rather than to principles. A subjects permissions > should be the same > regardless of how they are identified. (Of course, > other things can vary > the mapping, per our discussions redgarding > Scope/Context). > > [ snipped a whole bunch of stuff I agree with > completely =] > > > > > I still don't know what you plan to do with > fulcrum. Moreover, I would > > like to know if the basic functionality of TSM as > I implemented it is > > good enough for your purposes: > > > > Subject getSubject(String id) > > Permission getPermission(String id) > > > > Authenticator getAuthenticator(Subject > subject) > > => boolean checkSubjectCredentials(Subject > subject, > > Credentials credentials) > > Authorizer getAuthorizer(Subject subject) > > => boolean checkSubjectPermission(Subject > subject, > > Permission permission) > > > > Maybe the last two could be collapsed into a > single call through > > TSM, so that the caller would never know about > Authenticators and > > Authorizers: > > > > boolean checkSubjectCredentials(Subject > subject, > > Credentials credentials) > > boolean checkSubjectPermission(Subject > subject, > > Permission permission) > > I prefer this. > > > > > > I disagree. The code in fulcrum makes explicit > use of Roles and Groups. > > > One of the big pushes in the new design is to > simplify as much as possible > > > the design. I'm not saying Roles and Groups are > bad or anything; in fact, > > > I like role-based security, and probably would > use it almost everywhere. > > > But the basic implementation should be that: > basic. And of course it > > > should allow for role-based security. > > > > This is a good example of the flexibility of > Authorizers: you could define > > a new authorizer, RoleGroupAuthorizer, that would > answer the call to > > checkSubjectPermission by checking if the user > inherits the permission > > through any of his roles in the current group. > Notice that you could do > > this in a completely independent manner on how the > user is authenticated > > (against LDAP, /etc/passwd, whatever). > > We probably need to provide an implemntation of > authorizer which uses > roles in the classic turbine way. > > > Finally, since there seem to be several, pretty > different proposals floating > > around, how about this: I recommit my proposal > under o.a.t.s.gonzo, an Eric > > does likewise under o.a.t.s.eric. We leave a > SINGLE file under o.a.t.s, > > the empty interface SecurityManager. Jason chooses > whatever implementation > > he wants. Opinions? > > Only that instead of choosing one implementation we > try to merge both of > your proposals into one default implementation where > the parts that are > different are pluggable options. I figure if we > can't do this then are > pluggability isn't good enough. > > Good luck! > > -- jt > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
