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:[EMAIL PROTECTED]]
> > 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:[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]>
>
> --
> 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]>
