-
1. Re: Mapping Application Roles to Declarative Role
Anil,
Although this does not answer your question...
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.
Am I way off base? cgriffith -
2. Re: Mapping Application Roles to Declarative Role
"j2ee_junkie" wrote:
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.
Cannot include the mapping in the jboss DD because it will be like tying the mapping to a layer(web/ejb) when it should be at the security domain level for multple layers. -
3. Re: Mapping Application Roles to Declarative Role
I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml
<assembly-descriptor> <security-role> <role-name> <principal-name> </security-role> </assembly-descriptor>
This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role?
cgriffith -
4. Re: Mapping Application Roles to Declarative Role
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:
<application-policy name="security-domain-name">
<login-module>blahblah</login-module>
<role-mapping>
<application-role>whatever role from login module</application-role>
<deployment-role>whatever deployment role it should map to</deployment-role>
</role-mapping>
</application-policy>
Ofcourse this is just an example, and definitely needs better element names -
5. Re: Mapping Application Roles to Declarative Role
"j2ee_junkie" wrote:
I understand what you are saying and I am not necessarily disagreeing, but consider the following settings in jboss.xml<assembly-descriptor> <security-role> <role-name> <principal-name> </security-role> </assembly-descriptor>
This maps a principal to a role in the deployment. Isn't this very similar to mapping a role to a role?
cgriffith
Agreed. This is how WL/WebSphere do it. I still think it may be wise to put it at the security domain level via an external configuration. -
6. Re: Mapping Application Roles to Declarative Role
"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:
<policy>
<application-policy name="security-domain-name">
<authentication>
<login-module>blahblah</login-module>
</authentication>
<role-mapping>
<role>
<application-role>whatever role from login module</application-role>
<deployment-role>whatever deployment role it should map to</deployment-role>
</role>
</role-mapping>
</application-policy>
Ofcourse this is just an example, and definitely needs better element names
Close. The RoleMappingLoginModule uses a properties file to specify the mapping.
http://wiki.jboss.org/wiki/Wiki.jsp?page=RoleMappingLoginModule -
7. Re: Mapping Application Roles to Declarative Role
"anil.saldhana@jboss.com" wrote:
Close. The RoleMappingLoginModule uses a properties file to specify the mapping.
http://wiki.jboss.org/wiki/Wiki.jsp?page=RoleMappingLoginModule
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 -
8. Re: Mapping Application Roles to Declarative Role
"sohil.shah@jboss.com" wrote:
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. -
9. Re: Mapping Application Roles to Declarative Role
Scott,
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?
cgriffith -
10. Re: Mapping Application Roles to Declarative Role
Yes. This is already the case when you use the JACC provider, at least an implementation other than the current jboss default.
-
11. Re: Mapping Application Roles to Declarative Role
"j2ee_junkie" wrote:
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) -
12. Re: Mapping Application Roles to Declarative Role
"sohil.shah@jboss.com" wrote:
"j2ee_junkie" wrote:
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. -
13. Re: Mapping Application Roles to Declarative Role
Dear gang,
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.
Just my updated thoughts. enjoy, cgriffith -
14. Re: Mapping Application Roles to Declarative Role
"scott.stark@jboss.org" wrote:
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.