RE: [security] Authentication mechanism

["Alan D. Cabrera" <ad...@toolazydogs.com>]

> -----Original Message-----
> From: Jan Bartel [mailto:janb@mortbay.com]
> 
> 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

Re: [security] Authentication mechanism

[Jan Bartel <ja...@mortbay.com>]

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

thanks
Jan

Alan D. Cabrera wrote:
> 
>>-----Original Message-----
>>From: Jan Bartel [mailto:janb@mortbay.com]
>>
>>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