-
1. Re: JBoss Security Service Provider Interface Extension
anil.saldhana Aug 28, 2006 3:59 PM (in response to anil.saldhana)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) -
2. Re: JBoss Security Service Provider Interface Extension
anil.saldhana Aug 30, 2006 12:19 PM (in response to anil.saldhana)I have been wondering about the following for the SPI:
Security Caching and a mechanism to flush it.
Previously, the Security Caches were injected into the Security Manager via the JMX wrapper service and flush when needed was an aspect of the service.
Since caching is a necessity and information can change in the background in the sources (like db, ldap etc), I was wondering about providing a formal mechanism by which data that gets updated in the source will trigger a flush of the cache. (SPML is a good choice and we do have access to OpenSPML for integration)
This formal mechanism can be a JMX service that acts as the door to the information update (Currently I can see JBossPortal/Seam etc being the major users of this). I use the mechanism to update the roles in the Database, the mechanism updates the info in the DB while sending a flush to the Security Cache.
Making this mechanism generic for usage is a challenge. -
3. Re: JBoss Security Service Provider Interface Extension
starksm64 Aug 30, 2006 1:19 PM (in response to anil.saldhana)Explain why SPML is needed for this. Any push for SPML needs to be coming from the container MC project or the ESB as just introducing an SPML dependency in jbosssx does not make sense.
In terms of JMX, there has to be a POJO api for flushing that cache that can be fronted via JMX if desired. JMX is a managment implementation detail, not a dependency that we want to propagate further. -
4. Re: JBoss Security Service Provider Interface Extension
anil.saldhana Aug 30, 2006 1:57 PM (in response to anil.saldhana)Agree on the non-need to add SPML dependency into JBossSX.
The current interface for Cache (CachePolicy) does hold the ability to flush. So we can end the discussion on SecurityCache Flushing. -
5. Re: JBoss Security Service Provider Interface Extension
starksm64 Aug 30, 2006 6:13 PM (in response to anil.saldhana)I think the more general question is how to leverage jbosscache and related cache services to allow for integration with other invalidation frameworks.
-
6. Re: JBoss Security Service Provider Interface Extension
anil.saldhana Sep 4, 2006 9:49 AM (in response to anil.saldhana)We can give it a shot at using JBossCache as the cache for one security manager and then generalize it.