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 21:59:37 GMT
> 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.

Make no mistake, using option 1 as an interim solution is better than no
solution at all.  But I do believe that it should be a short term
solution...the -1 is attibuted to using it as the long term/permanent
solution.

The ultimate goal should be the ability to have 'n' number of dependencies
from a Collection perspective.  As time goes on, this will become more and
more of a necessity.  It makes more sense to have the option 2 solution in
the long term.

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

Agreed.


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