geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: [security] Authentication mechanism
Date Mon, 01 Dec 2003 04:33:56 GMT

> -----Original Message-----
> From: Jan Bartel []
> Alan,
> If it is the intention that the Subject is populated with a Principal
> for each role (aka group) obtained from the LoginModule/SecurityRealm
> login time, then I can see how this will work. What is confusing is
> 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

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
> for each of the security-role-ref/role-link and
>   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?


View raw message