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 Tue, 22 Jan 2002 02:46:52 GMT
Hey Mike,

You've described - quite well - the implementation I have in mind for the
JAASAuthenticationManager implementation.

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

What I meant by the above was that blocks written to a client api - was
defined - would have to be changed to the latest greatest mechanism if there
is no adequate abstraction layer.  Personally, I think that there will more
than likely be a JSR effort to target JAAS appropriately for the
server-side.

There are a few gotchas with the use of JAAS that make it somewhat
cumbersome on the server-side.

Changes there would potentially cause changes in the client api.

Others may consider JAAS overkill for their simple applications and not want
to add the (possibly) dangerous flexibility of JAAS login modules.  These
customers would provide a SimpleNonJAASAuthenticationManager. :-)

Anyway, I am concerned about locking blocks, yet developed, into any one
AuthN and AuthZ mechanism.

thanks,

--Larry

> -----Original Message-----
> From: Michael McKibben [mailto:mike@hihat.net]
> Sent: Monday, January 21, 2002 7:06 PM
> To: Avalon Developers List
> Subject: RE: AAA Security
> 
> 
> 
> Larry,
> 
> AFAIK (and this isn't saying much since I'm still learning phoenix),
> blocks currently don't work with any security api yet. Rather, they
> specify a standard java policy based on codebase in their 
> descriptor. I
> think this mechanism can be extended to use JAAS with the 
> required level 
> of flexibility by 
> 
> + Extend the descriptor format to allow a block to define 
> their own JAAS
> AppConfigurationEntry. E.g (just making this up)
> <auth realm="myRealm">
>  <module 
> name="org.apache.avalon.phoenix.security.DBLoginModule" 
> flag="required">
>    <option name="datasource" value="..."/>
>  </module>
>  
>   ...
> </auth>
> 
> + Use the new JAAS extended policy format instead of the codebase
> format. Or a just policy provider can be implemented by
> setting the policy.provider System property to the phoenix provider
> Implementation.
> 
> + Provide an implementation of javax.security.auth.login.Configuration
> which returns a block's configured AppConfigurationEntry[] on calls to
> getAppConfigurationEntry("myblock"). This is controlled via setting of
> the login.configuration.provider System property (Phoenix 
> would set this
> on startup.)
> 
> + Provide some implementations of javax.security.auth.spi.LoginModule
> (e.g. DBLoginModule, JNDILoginModule, SimpleXMLFileLoginModule)
> 
> Now if say I want to implement a ftp server with auth support. I just
> define an appropriate login module for my block in its descriptor (or
> should this live in the application descriptor?), define the 
> policy, and
> authenticate clients using JAAS. Single-Signon can be achieved by
> declaring the phoenix applications to be a part of the same security
> domain (i.e. realm).
> 
> JAAS by design allows flexibility on the SPI back-end. Does Phoenix
> require flexibility on the client end?
> 
> Again, I am just throwing this out there for consideration. JBoss does
> something similar to this and I've found it flexible enough 
> to implement
> single sign-on, multiple auth methods (file based, GSSAPI, ldap).
> 
> Regards,
> 
> --mike
> 
> On Mon, 21 Jan 2002, MCCAY,LARRY (HP-NewJersey,ex2) wrote:
> 
> > 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>
> 


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