This works perfectly fine for majority of the cases except for one, when there are login modules with the control flag of "Sufficient" and no "required/requisite" modules. The problem is that the optional RoleMapping LM will never be reached, if authentication succeeds.

Given this, there are alternatives:1) The user can override the getRoleSets method of any JBoss standard LM.2) The Abstract Server LM base class can be retroffited with role mapping logic.

Both the options hold merit in various usecases. Option 2 can solve majority of the user needs, but the issue is that we cannot tie the logic to a single store for role map, like the properties file as done by the RoleMappingLoginModule. This can require a override in all LM if users need to do it.

The right solution is logic should be added after the Jaas authentication process is completed. This will decouple the process from the login module life cycle. The above discussion holds true mainly for JBoss 4.0.x

As I see, I think we will need to add the logic into the JaasSecurityManager. The question is should we get the rolemapping setup for a particular security domain, by peeking into the jaas configuration. I welcome your thoughts on this topic.

Consider the current case where a developer of a j2ee component references some other component. This is done by name, correct? Then the deployer is resonsible for mapping between the application used name and the deployment environment name. So my point is that I would see this as a deployment issue with a need to modify to the ejb-jar.xml and web.xml descriptors. Of course that may not be possible.

If it can be seen that this is a deployment issue, and if web.xml or ejb-jar.xml do not cover these issues, then I would think that the jboss.xml file would need to contain this mapping.

"sohil.shah@jboss.com" wrote:Since it makes sense to associate this mapping at the security-domain level to be utilized at different layers of the app (not just ejb and web)(I am thinking Portal,SEAM, JBPM etc)

wouldn't it make sense to extend the configuration options in the login-config.xml so that you can specify the role/identity mappings kind of like this:

Right but the issue with using it this way with association with the LoginModule is that the LoginModule may not fire in 100% of usecases, as indicated.

Looks like we kind of need a way to specify the role-mapping independent of the LoginModule, so that the roles are populated without dependence on particular LoginModule

Correct. We need a separate authorization aspect(s) that can be applied to the authentication result to build up the authorization context independent of the authentication phase. Its a legacy overloaded usage of jaas that the login modules provide the declarative roles.

Are you saying that Login Modules really should just authenticate, and not authenticate and authorize?

Seems like the issue being addressed is who populates the Subject with role information (LoginModule or an Authorization aspect).

Decoupling this function from the LoginModule makes perfect sense.

The LoginModule does not do the actual *authorization enforcement*. That function is actually performed by the different layers in the application like (web,EJB,JACC,some XACL module etc)

Yes, and instead of just a Subject representing the security context, we should have a security context that contains a Subject, trust domain info, authorization info/pointers, etc to allow better integratin/reuse of authorization aspects.

Well after a good night's rest (something of a rarety these days with my 3mo old son) and a shot of coffee, the light bulb over the head finally turned on. I am reluctant to admit that it was not until then that I really understood the problem purposed and all of your suggestions.

That said, I would like to point out that the RealmMapping interface was designed to be a point of access for Principal to Role mapping. As such there needs to be a way to configure this mapping for the RealmMapping implementor to store and use. As Scott pointed out, currently this is a "legacy overloaded use of JAAS". I now understand and agree. Also, Scott has pointed out the benefits of creating a security context that can store this mapping, among other things. This is good, but it still does not explain how to configure the mapping. For that, I seem to agree with Anil and Sohil. The JaasSecurityManager as a RealmMapping should have a way to configure the mapping other than thru the use of the JAAS login. The login config then seems to be the logical place to be extended to provide a per security domain mapping.

Another idea that comes to mind is to create a new AuthenticationManager and RealmMapping class (for this discussion I will call it NewSecurityManager) that performs JAAS login to obtain identity (like JaasSecurityManager), but does not depend on Roles to be assigned to Subject. The login will just assign Principals to the Subject as JAAS intended.

Then a pluggable means to configure the mapping from Principals to Application Role could be created. Such pluggins could contact a persistent store (db, ldap, file) or be configured dynamically. The pluggin used would be a NewSecurityManager config parameter.

Yes, and instead of just a Subject representing the security context, we should have a security context that contains a Subject, trust domain info, authorization info/pointers, etc to allow better integratin/reuse of authorization aspects.

We can do the security context clean up in the time frame of JBoss 5.0.0.GA (50%) or 5.0.1 (100%).

I am wondering how difficult will it be for those users who have customized JBoss security or have had deeper integration, because keeping the overloaded subject with the roles/calleridentity/runasidentity logic after the cleanup, for backward compatibility, will be a nightmare in terms of manageability/complexity.