geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Conceptual problem with security auto-mapping?
Date Sat, 20 Nov 2004 07:22:00 GMT
I was thinking of keeping the info in the realm gbean, but setting it  
in the GBeanData instead of generating it in java code.  It doesn't  
even need to be stored in the gbean itself.

infoBuilder.addAttribute("defaultPrincipalClassName", String.class,  
infoBuilder.addAttribute("defaultPrincipalName", String.class, true);
infoBuilder.addAttribute("designatedRunAs", boolean.class, true);
infoBuilder.addAttribute("principalClassNames", Set.class, true);

<gbean name="x:name=myRealm" class="...">
   <attribute name="defaultPrincipalName">foo</attribute>
   <attribute name="designatedRunAs">true</attribute><!-- is this  
assumed true? -->

I can't say I understand it well, but I'm leery of a gbean which is  
running at both deployment and runtime.  This seems like it is  
overlapping concerns and possibly breaking the architecture.

david jencks

On Nov 19, 2004, at 10:21 PM, Alan D. Cabrera wrote:

> Into which GBean?  If you mean the container GBean then you would end  
> up
> with something akin to the current "full" role map settings and it
> looses its value as a convenience mechanism for automatic role mapping.
> If you mean a new GBean then you end up with my original proposal of
> divorcing the auto mapper from the security realms.
> I was thinking of having a separate, single, role mapping service.  The
> only reference you would have was to just this service.  Adding more
> mappings would be done "inside" this service and would not require
> adding to configuration plans.  This service would provide auto mapping
> as well as "live" role mapping services.  The former is used at
> deployment time and, once used, its mappings are frozen for that
> deployment.  The latter can be used when JACC is asked to make a
> decision.
> Regards,
> Alan
>> -----Original Message-----
>> From: David Jencks []
>> Sent: Friday, November 19, 2004 11:16 PM
>> To:
>> Subject: Re: Conceptual problem with security auto-mapping?
>> Looking at this again, I have a proposal.  The problem with putting
> the
>> automap functionality in a different place is that there is still no
>> good way to make it available at deployment time: you should be able
> to
>> deploy a new kind of realm easily without adding more stuff to the
>> builder configuration.  So, keeping the info in the realm seems like a
>> good idea.
>> Looking at what the info is, it's just a few strings and a boolean:
>> realm name, default principal class name, default principal name, run
>> as, and a set of principal class names.  We can put all of these in as
>> persistent properties.  This means we set them explicitly in the gbean
>> config, which is less convenient and much more error prone than coding
>> them, but they will be available at deployment time.
>> I wonder if we would want to support some kind of "constant"
> attributes
>> whose values are configured permanently in the GBeanInfo?
>> thanks
>> david jencks
>> On Nov 19, 2004, at 5:47 PM, Alan D. Cabrera wrote:
>>>> -----Original Message-----
>>>> From: David Jencks []
>>>> Sent: Friday, November 19, 2004 7:50 PM
>>>> I think there is a conceptual problem with the current auto-mapping
>>>> security code.
>>>> This should be done at deployment time (soon it will even be
> possible
>>>> for web apps).
>>>> However, the realms needed are going to be part of the server
>>>> configuration, not the ("static") deployment configuration.
> Therefore
>>>> they may or may not be started at deployment time.  It looks to me
> as
>>>> if the automapping requires the realm to be running in order to get
>>> the
>>>> default principal and set of principal classes.
>>>> So far I don't see a good solution to this problem.  Ideas?
>>> Here are my feelings:
>>> - The roles should be auto mapped at deployment time.  The auto
>>> generated role mappings are frozen at deployment time; this keeps
>>> things
>>> tractable.
>>> - The auto mappers should be divorced from the security realms.
>>> - We need to add live mapping mechanisms to our JAAC policy
>>> configurations but, this is a separate paradigm from auto mapping.
>>> Regards,
>>> Alan

View raw message