6 Replies Latest reply on Sep 4, 2006 9:49 AM by Anil Saldanha

    JBoss Security Service Provider Interface Extension

    Anil Saldanha Master

      I would like to dedicate this thread to the discussion of the extension of the JBoss Security SPI, to enable third-party integrators to better customize the JEMS Security layer.

      The current SPI from JBossSX is limited to the AuthenticationManager and RealmMapping interfaces, plus the ability to provide custom login modules, via a custom application-policy. This is the extent to which customization of JBossSX is provided.

      With the advent of federated identity plus various flavors of SSO and need for providing support for special security mechanisms like the SPNEGO authentication with Active Directory/GSS-API etc, there is a need to provide an extended JBoss Security SPI.

      To give you an idea of what SSPI is provided by Weblogic:

      and Websphere SPI:

      Some of the key areas where a SPI is needed:
      a) Auditing Capabilities.
      b) UserName Mapping.
      c) Role Mapping. (Map principals in the subject to a set of roles)
      d) Identity Token Mapping. (Map a token to a Principal)
      e) Certificate Mapping. (Map X509 certificate to a Principal)

      - Externalization of Tomcat Authenticators.
      - Work on JSR-196 externalization of authentication.

      - Discussion and prototype in HEAD.
      - Backport to Branch_4_0 once stable and if demand arises.

      Examples of products that can make use of JBossSX SPI:
      a) RSA ClearTrust that currently supports Weblogic and WebSphere.
      b) Entrust Secure IDM Soultion that works on WL.
      c) Oracle IDM that works with WL and WebSphere.

      Information to follow.

        • 1. Re: JBoss Security Service Provider Interface Extension
          Anil Saldanha Master

          Here is a snip of the configuration that drives the role mapping logic.

          <?xml version="1.0" encoding="UTF-8"?>
           <mbean code="org.jboss.security.auth.login.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"
           <jbsx:application-policy name="jbossweb-role-map">
           <jbsx:module-option name="principal">SpecialUser</jbsx:module-option>
           <jbsx:module-option name="roles">testRole</jbsx:module-option>
           <jbsx:mapping-module code="org.jboss.security.mapping.providers.OptionsRoleMappingProvider">
           <jbsx:module-option name="rolesMap"
           <java:properties xmlns:java="urn:jboss:java-properties"
           xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd">
           <jbsx:module-option name="replaceRoles">false</jbsx:module-option>
           <depends optional-attribute-name="LoginConfigService">
           <depends optional-attribute-name="SecurityManagerService">

          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 Saldanha Master

            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
              Scott Stark Master

              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 Saldanha Master

                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
                  Scott Stark Master

                  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 Saldanha Master

                    We can give it a shot at using JBossCache as the cache for one security manager and then generalize it.