geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Question about role-mapping specificity
Date Wed, 22 Dec 2004 19:19:34 GMT
	Originally, the RealmPrincipal had security realm name and 
principal class and principal name.  We decided this didn't work if you 
wanted your security realm to span two of the same type of login domain -- 
for example, an "accounting" LDAP server and an "IT" LDAP server.  In that 
case, the principal classes would be the same and the security realm would 
be the same, so principal "Foo" from one LDAP server would appear 
identical to principal "Foo" from the other LDAP server.  I attempted to 
argue that this wasn't a realistic scenario, but I've been convinced that 
we should support it.

	So the conclusion then was to switch from security realm name to
login domain name, so the RealmPrincipal would have login domain name,
principal class, and principal name.  We kicked around the idea of
security realm being important -- perhaps you have two realms wrapping the
same login domain, and one realm audits and the other doesn't, and you
want to ensure that the user signed on via the auditing realm.  But in the 
end we decided that this wasn't necessary.

	My last concern is if you have apps from two different sources in
the same server, each with their own security realm.  What happens if they
both independently decide to use the same login domain name (both for the
same realm type, such as the default Geronimo RDBMS realm)?  Will that
grant a user form one app access to the other app totally by accident?  
It seems like that would only happen if you log in to app A, and then try
to access app B, and Geronimo uses your existing Subject rather than
storing a separate Subject for each app.  I haven't yet decided whether
that would happen.  If it does happen, then do we need to keep the
security realm name (though what if they independently pick the same realm
name *and* the same login domain name?)?.  Perhaps we should make it the
case that if you deploy a security realm within an EAR, it's not possible
to use those principals to access resources outside the EAR.  Then you'd
need to deploy all your connectors in the EAR too, but we're talking about
an ISP-style scenario where there wouldn't really be any "common
server-wide resources", so that would make sense.  I'm just not sure how
feasible it is to implement.

	Anyway, I changed the RealmPrincipal over to use login domain name 
instead of realm name, but I didn't remove the realm name argument from 
the calls to the constructor in case we decided it was important later.  
That's why it's still hanging out as an argument but not used in any of 
the real computations.  I admit, that's pretty dumb.  :)


On Tue, 21 Dec 2004, David Jencks wrote:
> 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 
> using.
> 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