geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Question about role-mapping specificity
Date Wed, 22 Dec 2004 01:21:36 GMT
I've been studying the role mapping code a bit, partly due to trying to 
get auto-mapping to work during deployment.  I'd like to tidy up the 
loose ends and get everything consistent.

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,


(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 

Depending on the answer to this question, we need one of two changes 

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

View raw message