geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [security] Authentication mechanism
Date Mon, 01 Dec 2003 20:48:23 GMT
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 :-)


Alan D. Cabrera wrote:
>>-----Original Message-----
>>From: Jan Bartel []
>>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
>>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()
> 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

View raw message