In JBoss Application Server v5.0 and beyond, it is possible to map roles from the ones derived at the security domain level to include additional roles included in deployment (such as at the EAR level).

Mapping Provider: 

org.jboss.security.mapping.providers.DeploymentRolesMappingProvider

Configuration:

Preferred:

<application-policy name="some-sec-domain">
<authentication>
...
</authentication>
<mapping>
   <mapping-module code="org.jboss.security.mapping.providers.DeploymentRolesMappingProvider"
                   type="role"/>
</mapping>
...
</application-policy>

Deprecated:

<application-policy name="some-security-domain-name">
  <authentication> .... </authentication>
  <rolemapping>
      <mapping-module code="org.jboss.security.mapping.providers.DeploymentRolesMappingProvider"/> 
  </rolemapping>
</application-policy>

Now you cna have deployment level role mapping, as follows:

In jboss.xml  or jboss-web.xml, you can have something like:

 <assembly-descriptor>
    ...
    <security-role>
      <role-name>Support</role-name>
      <principal-name>Mark</principal-name> 
      <principal-name>Tom</principal-name>
    </security-role>
    ...
  </assembly-descriptor>

In normal cases, this is viewed as the addition of roles to a RunAsIdentity as described in here

But if you include this mapping configuration element in your security domain configuration with the DeploymentRolesMappingProvider, you are essentially forcing an additional interpretation of roles to be added to a particular principal for this particular deployment (war, ear, ejb-jar etc).