We can create a mapping server. The DD has the configuration that dictates the role mapping policy that the role mapping service is to use. The out of the box role mapping can be generate a role mapping and freeze it at the first container startup. The server would have a run-time management interface that would allow us to inspect the mappings. We could also use the run-time interface to change the role mapping while the app is running.
Regards, Alan > -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 05, 2005 8:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [jira] Commented: (GERONIMO-454) Support Group Name = Role > Name Role Mapping > > On Jan 5, 2005, at 4:12 PM, Alan D. Cabrera wrote: > > > I am not arguing against automapping, I am arguing against automapping > > taking place at after the delivery of the DDs. I am also not arguing > > for users writing our DDs directly. > > > > Your analogy to CMP mapping is not quite the same as automapping of > > roles for a number of reasons. DB schema is not as likely to change > > and > > when it does, the results are immediately known; role automapping can > > have unwanted results that may not be discovered for a long time, if > > ever. The CMP automapping always results in the exact same mapping, > > the > > role automapping does not. > > The last thing we want is for security to be difficult to use. If it > is, then no one will use it and we are worse off. Is there some > solution you are thinking of that is easy or automatic? I'm not > talking about complex security setups, but the simple ones. The simple > stuff should be simple and the complex stuff possible. > > -dain >
