Steve, > > Using this mechanism, we have a standard vehicle to use as > a security > > context and a standard mechanism to acquire it from the > thread context - > > Subject.getSubject(). > > > > We are not obligated to use JAAS login modules or JAAS > policy as the only > > mechanisms for authentication and authorization. > > This last sentence ... do you mean that in using JAAS we can > take advantage > of > authentication policy configuration mechanisms (that allows pluggable > authentication > mechanisms), or, that this would not be an obligation ?
I mean that just because we are using JAAS subject as a security context of sorts there is nothing that dictates our use of it be ONLY JAAS authentication and authorization. If we implement the client api as a proprietary abstraction we can implement the underlying mechanisms as whatever deemed appropriate. The only thing is that if we want at least implementation to be JAAS then the client side needs to be aware of Subject and doAs() so that the security context is available to all implementations. If we were to come up with a completely proprietary mechanism then it would be difficult to plug in a JAAS implementation underneath. Does this rambling make sense? - Haven't had enough caffeine yet. > -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 20, 2002 11:37 PM > To: Avalon Developers List > Subject: RE: AAA Security > > > > > > -----Original Message----- > > From: MCCAY,LARRY (HP-NewJersey,ex2) > [mailto:[EMAIL PROTECTED]] > > Sent: Monday, 21 January, 2002 05:12 > > To: '[EMAIL PROTECTED]' > > Subject: AAA Security > > > > > > All, > > > > Attached is quite a busy collaboration diagram describing the > > interaction of > > the potential players in the AAA implementation. > > > > A couple things that need to be determined - the client > facing api for: > > 1. Authentication > > a. JAAS client api > > b. proprietary api to abstract authentication > mechanism - > > including JAAS > > > > 2. Authorization > > a. J2SE authorization api's > > b. proprietary api to abstract implementation > > > > I am inclined to try and provide an abstraction through > proprietary api. > > > > With that said, I think that we need to assume the use of > the JAAS subject > > as a vehicle for identity and attribute principals and > credentials. The > > subject would follow the user through the request/session through > > the use of > > Subject.doAs() and/or doAsPrivileged() - this basically > associates the > > subject with the current thread of execution. > > > > Using this mechanism, we have a standard vehicle to use as > a security > > context and a standard mechanism to acquire it from the > thread context - > > Subject.getSubject(). > > > > We are not obligated to use JAAS login modules or JAAS > policy as the only > > mechanisms for authentication and authorization. > > This last sentence ... do you mean that in using JAAS we can > take advantage > of > authentication policy configuration mechanisms (that allows pluggable > authentication > mechanisms), or, that this would not be an obligation ? > > Cheers, Steve. > > > > Any thoughts? > > > > thanks, > > > > --Larry > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
