What if the JAAS api was used on the client side, and a custom LoginModule that uses the AAA framework was written instead? Just a thought.
Regards, --mike On Mon, 21 Jan 2002, MCCAY,LARRY (HP-NewJersey,ex2) wrote: > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
