Here is a snip of the configuration that drives the role mapping logic. | <?xml version="1.0" encoding="UTF-8"?> | <server> | <mbean code="org.jboss.security.auth.login.DynamicLoginConfig" | name="jboss.security.tests:service=DynamicLoginConfig"> | <attribute name="PolicyConfig" serialDataType="jbxb"> | <jbsx:policy xsi:schemaLocation="urn:jboss:security-config:5.0 resource:security-config_5_0.xsd" xmlns:jbsx="urn:jboss:security-config:5.0" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> | <jbsx:application-policy name="jbossweb-role-map"> | <jbsx:authentication> | <jbsx:login-module | code="org.jboss.security.auth.spi.IdentityLoginModule" | flag="required"> | <jbsx:module-option name="principal">SpecialUser</jbsx:module-option> | <jbsx:module-option name="roles">testRole</jbsx:module-option> | </jbsx:login-module> | </jbsx:authentication> | <jbsx:rolemapping> | <jbsx:mapping-module code="org.jboss.security.mapping.providers.OptionsRoleMappingProvider"> | <jbsx:module-option name="rolesMap" | serialDataType="jbxb"> | <java:properties xmlns:java="urn:jboss:java-properties" | xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" | xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd"> | <java:property> | <java:key>testRole</java:key> | <java:value>AuthorizedUser,InternalUser</java:value> | </java:property> | </java:properties> | </jbsx:module-option> | <jbsx:module-option name="replaceRoles">false</jbsx:module-option> | </jbsx:mapping-module> | </jbsx:rolemapping> | </jbsx:application-policy> | </jbsx:policy> | </attribute> | <depends optional-attribute-name="LoginConfigService"> | jboss.security:service=XMLLoginConfig | </depends> | <depends optional-attribute-name="SecurityManagerService"> | jboss.security:service=JaasSecurityManager | </depends> | </mbean> | </server> | In the SecurityContext.setRoles call, a call is made out to the rolemapping framework to update the roles (if needed). The interface for the MappingProvider is: | package org.jboss.security.mapping; | | import java.util.Map; | public interface MappingProvider | { | /** | * Initialize the provider with the configured module options | * @param options | */ | void init(Map options); | | /** | * Map the passed object | * @param map A contextual map that can provide information to the provider | * @return mapped result | */ | Object performMapping(Map map); | } | The generic MappingContext class is: | package org.jboss.security.mapping; | | /** | * Generic Context used by the Mapping Framework | */ | public class MappingContext | { | private List modules = new ArrayList(); | | public MappingContext(List mod) | { | this.modules = mod; | } | | /** | * Apply mapping semantics on the passed object | * @param obj Generic Object | * @return Mapped Object | */ | public Object performMapping(Map obj) | { | int len = modules.size(); | Object returnObj = null; | | for(int i = 0 ; i < len; i++) | { | MappingProvider mp = (MappingProvider)modules.get(i); | returnObj = mp.performMapping(obj); | } | | return returnObj; | } | } | This forms the basis for the mapping framework. The MappingContext/MappingProvider combination will work for the use cases currently identified. The locations where the various mapping sematics (identity, certificate, rolemapping etc) need to be applied in the call path needs to be identified (but should be easy). A similar setup exists for the Auditing framework with pluggable audit providers configured at the security domain level (TODO) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967909#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...