geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Genender" <jgenen...@savoirtech.com>
Subject Re: Proposal for login modules for a GenericSecurityRealm
Date Thu, 28 Apr 2005 20:52:34 GMT
dj,

-1 on option 1...this can get really messy and ugly with many plans and
many login modules.

+1 on number 2.  It would be nice to have support for a model that allows
a dependency on several gbeans to ensure they have started.  I think this
would have been very helpful in a number of areas, and especially would
have been helpful for the tomcat plan.  Therefore this would be good not
just for the Security objects...we could use this functionality in other
areas.

> At the moment there is a problem with GenericSecurityRealm.  The
> loginModuleConfiguration attribute takes, effectively, a list of login
> domain gbeans, and GenericSecurityRealm expects them all to be started.
>   There is no way at the moment to constrain them to be started:
> sometimes it works and sometimes it doesn't.
>
> I can think of 2 approaches to solve this problem.
>
> (1) (can be implemented now).  Write a LoginModuleHolder gbean that has
> a reference to the login domain gbean and a next LoginModuleHolder,
> thus forming a linked list.  The GenericSecurityRealm gets a reference
> to a LoginModuleHolder, so it won't start until all the login modules
> have started.  Additional attributes such as the
> REQUIRED/OPTIONAL/SUFFICIENT flag can be included in the
> LoginModuleHolder gbean.
>
> advantages:  can be done now fairly simply.
>
> disadvantages: creates a lot of gbeans with no function except
> dependency management, will be a real nuisance to set up without some
> kind of builder support.  It might be possible to use an xml-attribute
> on the GenericSecurityRealm to generate the extra gbeans.
>
> (2) (would require kernel changes)  Add a new reference collection type
> that is something like an ordered list of explicitly named references.
> If the objects in the list could be something with additional
> attributes, perhaps even something described by  a GBeanInfo, that
> would be even better.
>
> advantages: avoids extra gbeans that don't really do anything.  Elegant
> solution.
>
> disadvantages: complicates kernel and may be difficult to implement.
> Anyway it requires new functionality.
>
> There's already a similar situation in the Jetty integration with
> filter holders, which are a linked list of gbeans with little function
> other than to make things happen in a particular order.  So, there are
> at least 2 places that would benefit from (2).
>
> While we discuss this I plan to implement (1) for the
> GenericSecurityRealm.
>
> thanks
> david jencks
>


Mime
View raw message