Here's a summary of what (should) happen when you log in for a j2ee app:
1. Your choice of client determines the GenericSecurityRealm you log into via a securityRealmName parameter somewhere in the plan for the client (or other configuration for a non-j2ee client) [currently securityRealmName is mislabeled loginDomainName in the jetty plan]
2. The GSR has a bunch of LoginModules labeled with loginDomainNames (and a bunch of unlabeled ones that don't generate any principals). As you log into a LoginModule, geronimo wraps the principals from the login module(s) with RealmPrincipals containing the GSR realmName, the LM loginDomainName, and the principal. [currently the GRS realm name is ignored, this is the basis of half of my question]
3. You end up with a Subject containing all the LM principals and all the wrappers around these principals. This is attached to the invocation/thread of execution.
4. When you try to do something, geronimo consults the role mapping to see if any principals you have are mapped to any of the roles that have the permission you need.
So, lets take a look at the role mapping:
Obviously, it needs to be a mapping from these RealmPrincipals to roles. Thinking about it from a mathematical or geometric perspective, there are 4 dimensions to a RealmPrincipal: realmName, loginDomainName, (wrapped) principal class, and (wrapped) principal name. Or, the mapping is a subset of, where X means cartesian product,
RN X LDN X PC X PN X R
(R is roles)
However, currently the xml security schema does not include the LDN component, specifying RN X PC X PN X R. Obviously there is a problem or two, leading to my questions.
Is it correct to ignore the realm name in the RealmPrincipal?
I've tried to think up an example where this could make a difference. So, suppose we have a LDAP login module connected to the mythical corporate security system for our single login domain, and some ejb application. We set up GSR1 and GSR2 both including this login module/domain. We have a web app using GSR1 to log in and an app client using GSR2 to log in, and both these apps call the same ejbs. So, Joe logs in, and the ldap system identifies him as a member of the foo group.
-- if we include the GSR realm name in the role mapping, we can make it so Joe is allowed to do different things with the ejbs based on whether he is using the web app or the app client for access.
--if we do not include the GSR realm name in the role mapping, Joe will be able to do the same things with the ejbs no matter which app he is using.
Depending on the answer to this question, we need one of two changes (IIUC, IMO)
-- if we ignore the realm name, the role mapping should be a subset of LDN X PC X PN X R. I think this can be implemented by changing "realm-name" to "login-domain-name" in the xml and following the path where this is used through the code.
-- If we do not ignore the realm name, then realmName should be included in RealmPrincipal and login-domain-name should be added to the role mapping. I suggest adding the login-domain-name as an attribute of principalType in the schema, although another element layer could be used instead.
Personally I lean towards including the realmName but I have been known to favor excessive complexity in the past. In particular, there may be an alternative way to get the effect of different permissions based on which app Joe is using, by making 2 copies of the login module, each labelled with a different loginDomainName.
Many thanks, david jencks
