geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Conceptual problem with security auto-mapping?
Date Sat, 20 Nov 2004 08:02:09 GMT
	Just a note on this conversation -- with the switch to
GenericSecurityRealm, the auto-mapping configuration is along the lines
you suggest below.  Currently it goes like this:

addAttribute("defaultPrincipal","someuser=a.b.c.UserPrincipal");
addAttribute("autoMapPrincipalClasses","a.b.c.Group,a.b.c.Organization,...");

	If you want to change these properties to make it exactly like you
suggest below, that's totally OK -- I just put in something quick and
dirty for now.

Aaron

On Fri, 19 Nov 2004, David Jencks wrote:
> 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,  
> true);
> 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="defaultPrincipalClassName">o.a.g.Principal1</attribute>
>    <attribute name="defaultPrincipalName">foo</attribute>
>    <attribute name="designatedRunAs">true</attribute><!-- is this  
> assumed true? -->
>    <attribute  
> name="principalClassNames">o.a.g.Principal1,o.a.g.Principal2,o.a.g.Princ 
> ipal3</attribute>
> ...
> </gbean>
> 
> 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.
> 
> thanks
> 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 [mailto:djencks@apache.org]
> >> Sent: Friday, November 19, 2004 11:16 PM
> >> To: dev@geronimo.apache.org
> >> 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 [mailto:djencks@apache.org]
> >>>> 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
> >>>
> >>>
> >>
> >
> >
> 
> 

Mime
View raw message