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 Thu, 28 Apr 2005 21:19:48 GMT

On Apr 28, 2005, at 1:52 PM, Jeff Genender wrote:

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

I don't think (1) is necessarily a good permanent solution, but it has 
the advantage over the current state of affairs in that it works and 
the advantage over (2) that it can be implemented with a trivial amount 
of work.  With an editor we may be able to make it easy to use (i.e. 
easier than the current property file).  Even without an editor I don't 
think it will be significantly harder than the properties file.

If you want to insist on your -1, what do you suggest we do until (2) 
can be implemented?   I suggest you take a look at the actual 
implementation of (1) that I am almost done with :-) and see if it as 
bad as you fear.

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

Well I agree but dain says (2) will be rather hard to implement.  I 
certainly think it requires extensive discussion about what exactly we 
want.

thanks
david jencks

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