avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MCCAY,LARRY (HP-NewJersey,ex2)" <lawrence_mccay-...@hp.com>
Subject RE: AAA Security
Date Mon, 21 Jan 2002 21:45:52 GMT
Mike,

I have considered using the JAAS api on the client side - but I think that
this approach would preclude the use of non-JAAS authentication mechanisms
without requiring changes across existing blocks.

Do you have any thoughts as to whether:
 1. this would be an actual issue or not 
 2. there is a way to maintain the flexibility of a proprietary api while
retaining the use of the JAAS standard mechanism?

Thanks for the input,

--Larry

> -----Original Message-----
> From: Michael McKibben [mailto:mike@hihat.net]
> Sent: Monday, January 21, 2002 3:36 PM
> To: Avalon Developers List
> Subject: RE: AAA Security
> 
> 
> 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:mcconnell@osm.net]
> > > 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:lawrence_mccay-iii@hp.com]
> > > > Sent: Monday, 21 January, 2002 05:12
> > > > To: 'avalon-dev@jakarta.apache.org'
> > > > 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:avalon-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
<mailto:avalon-dev-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message