Hi Alan,
Before I get into a detailed analaysis/reply, can I just ask you to clarify what code is checked in and what is future plans? Eg, I've just done a cvs update and there is no NTLoginModule, SolarisLoginModule. BTW, I can't see any provision in the Geronimo deployment descriptors (at least geronimo-web) for Principal->Role mapping elements.
I can't work out from your verb tenses what is present and what is future so having a roadmap would certainly help :-)
thanks Jan
Alan D. Cabrera wrote:
-----Original Message----- From: Jan Bartel [mailto:[EMAIL PROTECTED]
Alan,
If it is the intention that the Subject is populated with a Principal for each role (aka group) obtained from the LoginModule/SecurityRealm
at
login time, then I can see how this will work. What is confusing is
that
this doesn't seem to be implemented in the code so far (at least I couldn't see where the roles were populated into the Subject in the
SQL
and FileProperties LoginModules).
You can have a group Principal per role, if you want to; this would then
accommodate the scenario that you mentioned earlier. However, I don't
force you to do so. It's all up to how the LoginModules for the
Security Realms are configured and how you setup your deployment
descriptor.
Subjects are not populated by roles, they are populated with Principals from LoginModules; some of these LoginModules can be vanilla LoginModules, e.g. NTLoginModule. This allows for simple mapping mechanisms for architects with simple needs. Should someone need something fancier, say the scenario you mentioned earlier, this can be easily accommodated within this simple paradigm.
Do you really think it is essential to have a principal<->role mapping in the geronimo-web.xml? Could it be possible to just create a
Principal
for each of the security-role-ref/role-link and
security-role/role-names
to which the WebRoleRefPermissions are assigned?
You can do that with the current mechanism, if you want. Just pick the
representative Principal and map it to the role. What I would like to
avoid is dictating to the application architect that they *must* create
representative Principals that map to application roles.
PS Just one more slight confusion - the SecurityRealms have methods getUserPrincipals() and getGroupPrincipals() that actually return collections of Strings not Principals - do you think maybe they should be renamed to getUserPrincipalNames() and getGroupPrincipalNames() instead?
You've hit upon a "todo" area. I was thinking that those methods would be used when someone is creating a deployment descriptor. However, the problem is that a SecurityRealm can have multiple kinds of Principals. Look at NTLoginModule and SolarisLoginModule. NTLoginModule can fill a Subject with a NTUserPrincipal, NTDomainPrincipal, NTSidUserPrincipal, NTSidDomainPrincipal, NTSidGroupPrincipals, and NTSidPrimaryGroupPrincipal. What do you think?
Regards, Alan
