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:[EMAIL PROTECTED]
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





Reply via email to