> -----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
