> 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]>
