3 Replies Latest reply on Aug 27, 2012 12:21 PM by dward

    Pluggable PolicyProviders

    dward

      As part of the work for SWITCHYARD-830, I needed a way to configure a SecurityPolicy "PolicyProvider" and associate it with those services who will use it to authenticate (or whatever the security action is) and provide the appropriate SecurityPolicy.  A couple examples of providers are PicketBoxSecurityPolicyProvider (which can do in-container authentication) and PicketLinkSecurityPolicyProvider (which can do out-of-container federated trust actions).

       

      The problem is the configuration.  What I did was create this structure:

       

      <switchyard>
          <composite>
              <service>...
              <component name="FooService">
                  <implementation.xyz>...
                  <service name="FooService" requires="confidentiality">....
              </component>
          </composite>
          <domain>
              <policy-providers>
                  <policy-provider class="org.switchyard.security.picketlink.PicketLinkSecurityPolicyProvider" services="FooService/FooService, BarService/BazReference">
                      <properties>
                          <property name="TokenType" value="SAML2"/>
                          <property name="ServiceName" value="PicketLinkSTS"/>
                          <property name="Port" value="PicketLinkSTSPort"/>
                          <property name="EndpointUri" value="http://localhost:8080/picketlink-sts-1.0.0/PicketLinkSTS"/>
                      </properties>
                  </policy-provider>
              </policy-providers>
          </domain>
      </switchyard>
      

       

      How this works is that inside the SwitchYard ExchangeHandler chain, there is a PolicyHandler that is created with a PolicyProviderRegistry.  The PolicyProviderRegistry holds mappings of service QNames to PolicyProviders that will attempt to provide any required policies dynamically.  The PolicyHandler 1st sees what Policies are required, then tries to apply based on matches in the PolicyProviderRegistry, then any leftover Policies that have not been met will cause a HandlerException to be thrown.

       

      So anyway, the above works, however I'm worried that I've added something that can be better done using the SCA spec, through the use of "policySet"s.  Here's an example from the SCA Policy Framework documentation:

       

      <policySet name="AuthenticationPolicy"

            provides="serverAuthentication"

            appliesTo="//binding.ws"

            xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">

         <e:policyConfiguration xmlns:e=”http://example.com”>

            <e:authentication type = “X509”/>

               <e:trustedCAStore type=”JKS”/>

               <e:keyStoreFile>Foo.jks</e:keyStoreFile>

               <e:keyStorePassword>123</e:keyStorePassword>

            </e:authentication>

         </e:policyConfiguration>

      </policySet>

       

       

      This seems to be what I'm looking for. Should I change to use this mechanism instead?

        • 1. Re: Pluggable PolicyProviders
          dward

          PS: In the example above, it should read: requires="clientAuthentication" not requires="confidentiality". That was just a quick-typo.

          • 2. Re: Pluggable PolicyProviders
            kcbabo

            As we discussed in the meeting this morning, it's probably best to have the domain configuration apply to all services in the domain.  Each service can still set it's own policy (e.g. secured, transacted, etc.), but the provider configuration is shared across the domain.  Applications/services which require a different provider config should be deployed in a separate domain.

            • 3. Re: Pluggable PolicyProviders
              dward

              Cool.