JBoss 4.2 related discussion

[anil.saldhana]

Topic: Support deployment level principal-role mapping via jboss.xml.

If there is deployment level principal-role mapping done by the user, we should be able to take this into account during authorization decisions.

Here is an example of this mapping:

<jboss>
 <assembly-descriptor>
 <security-role>
 <role-name>Administrator</role-name>
 <principal-name>j2ee</principal-name>
 </security-role>
 <security-role>
 <role-name>Employee</role-name>
 <principal-name>javajoe</principal-name>
 <principal-name>j2ee</principal-name>
 </security-role>
 </assembly-descriptor>
</jboss>

This info is available in the metadata and can be obtained in the JBossSX layer.

The previous approach of "DeploymentRolesLoginModule" was unaccepted.
http://www.mail-archive.com/[e-mail]/msg65476.html

Any ideas about solving this properly?

[starksm64]

We just need to support the introduction of static roles. Where authentication is done to obtain a Subject, a post authentication interceptor can be added to optionally associated deployment level roles + mappings. This interceptor would have to be in between the authentication and authorization interceptors.

In the web container, the construction of the JBossGenericPrincipal roles needs to consult the deployment metadata.

[anil.saldhana]

We just need to support the introduction of static roles. Where authentication is done to obtain a Subject, a post authentication interceptor can be added to optionally associated deployment level roles + mappings. This interceptor would have to be in between the authentication and authorization interceptors.

In the web container, the construction of the JBossGenericPrincipal roles needs to consult the deployment metadata.

That made perfect sense. Thanks Scott.

[anil.saldhana]

An issue that I did not originally think of, is the subject after authentication is read-only. Cannot do much about adding roles into the subject.

The PolicyContext getContextSubject is creating a read-only subject in the SubjectPolicyContextHandler

theSubject = new Subject(true, principalsSet,
 activeSubject.getPublicCredentials(),
 activeSubject.getPrivateCredentials());

I can probably use the SecurityAssociation.getSubject in the intermediate interceptor such that during authorization, the getContextSubject can return the read-only subject.

[starksm64]

The PolicyContext would just be a copy even if it was not read-only. One way would be to simply add the roles to the invocation and update the authorization interceptor logic to look there in addition to the RealmMapping.doesUserHaveRole call. Not having the roles assigned to the Subject is the direction we are heading anyway.

[anil.saldhana]

There is no need to add the roles to the invocation. The principal to role mapping can be obtained via the org.jboss.metadata.AssemblyDescriptorMetaData principal to role mapping, which is available on the container passing into the interceptor.

For 5.0, this is not an issue as we can use role mapping logic before authorization in the build up of the security context.

[starksm64]

ok, good.