geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Proposal for login modules for a GenericSecurityRealm
Date Fri, 29 Apr 2005 14:08:37 GMT

On Apr 29, 2005, at 5:06 AM, Aaron Mulder wrote:

> 	Are we strongly opposed to one GBean calling for another to be
> started?  For example, the realm looks up the login modules, if they're
> not available dies, if they're available but not started starts them, 
> and
> if they're available and started continues...  I guess this could cause
> problems where a number of GBeans are "half started" while waiting for
> others to start -- but it would be a third option.

With our current login modules I don't think there is any possibility 
that one will be "half started".  The problem occurs because currently 
there is no way to assure that a login module used by a realm has been 
created by the time the realm tries to start, short of putting it in a 
parent configuration.  The same xml compiled on different systems can 
result in success on one and failure on another.

>  Still, I like #2 the
> best.  It could be just a "list" of GBeans rather than a "collection" 
> of
> GBeans.

Personally I think that we need to be able to associate more info to 
each list member for this to be useful: in this case the control flag.  
Unfortunately saying "just" does not make any version of this idea easy 
to implement according to Dain.

thanks
david jencks

>
> Aaron
>
> On Thu, 28 Apr 2005, David Jencks wrote:
>> 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