geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Proposal for login modules for a GenericSecurityRealm (please approve or object)
Date Thu, 28 Apr 2005 23:27:07 GMT
So, I entered a bug () and have an implementation of (1).  Typical  
configuration changes are from:

     <gbean name="demo-properties-realm"
         class="org.apache.geronimo.security.realm.GenericSecurityRealm">
         <attribute name="realmName">demo-properties-realm</attribute>
                 <attribute name="loginModuleConfiguration">
                      
LoginModule.1.REQUIRED=geronimo.server: 
j2eeType=LoginModule,J2EEServer=geronimo,J2EEApplication=null,J2EEModule 
=org/apache/geronimo/Secure,name=demo-properties-login
                 </attribute>
         <reference name="ServerInfo">
             <module>org/apache/geronimo/System</module>
             <name>ServerInfo</name>
         </reference>
     </gbean>

  to

     <gbean name="demo-properties-realm"
         class="org.apache.geronimo.security.realm.GenericSecurityRealm">
         <attribute name="realmName">demo-properties-realm</attribute>
         <reference name="ServerInfo">
             <module>org/apache/geronimo/System</module>
             <name>ServerInfo</name>
         </reference>
         <reference name="LoginModuleConfiguration">
             <name>demo-properties-login</name>
         </reference>
     </gbean>

     <gbean name="demo-properties-login"  
class="org.apache.geronimo.security.jaas.JaasLoginModuleUse">
         <attribute name="controlFlag">REQUIRED</attribute>
         <reference name="LoginModule">
             <name>demo-properties-login</name>
         </reference>
     </gbean>

  It's slightly longer, but doesn't require you to figure out the entire  
gbean name of the login module.... so I think it is overall simpler :-)

Using an xml attribute builder won't work because we are trying to  
build a reference pattern, not an attribute value.  I suppose we could  
come up with a concept of an xml reference builder that adds gbeans and  
supplies an object name pattern, but I'm not convinced that would be of  
general use.

I think that the security configuration is still too complicated to  
expect people to configure via gbeans and think that a specialized xml  
format and builder for setting up login modules, realms, etc etc may  
provide a way to make setting up security actually comprehensible :-)

Meanwhile we can continue pushing on Dain to implement a List of  
References in the kernel ;-)

Does anyone object if I commit my current solution?

thanks
david jencks







On Apr 28, 2005, at 2:59 PM, Jeff Genender wrote:

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