Security-per-environment using config plans

Software artifacts normally flow through several environments; for example development, test, integration, acceptance, and production. Some piece of software may be developed locally on your laptop, can be deployed to a central test environment by a developer, scheduled for deployment to the integration environment by the build manager, and then formally promoted to acceptance and production by system administrators after successful testing. These various environments rarely look the same. While a production environment might consist of a clustered and load-balanced configuration with multiple servers running on Linux, your development environment may consist of a bunch of laptops all running a single integrated server on Windows.

Not only sizing, server versions, hardware specs, and OS specifics can vary between these environments, also security configuration. It could be that the production environment enforces SSL/TLS for all internal and external Web Service calls, only uses official certificates issued by a trusted CA, applies WS-Security based message encryption for outbound Web Service calls, uses WS-Security SAML Tokens for authentication, and an appliance for SSL offloading instead of the application server itself. Maybe in the integration environment self-signed certificates and WS-Security UserName Tokens are used, while the development environment enforces no security measures whatsoever.

One way to deal with environment-specific settings is to manually configure these settings while promoting software items from one environment to the other. Maybe this is manageable for a small and simple application, this approach will soon be error-prone and high-maintenance when the size of the application increases. This is especially the case in SOA systems, where there is a high(er) number of different software components involved. A different approach is to use scripting and automated builds in which settings can be configured per environment.

Oracle SOA Suite 11g uses so-called config(uration) plans for this purpose. Environment-specifics like Web Service endpoint locations invoked by an SCA composite can be extracted from the SCA composite and stored in an XML config plan per environment. So we could have a MyComposite_cfgplan_dev.xml that indicates the endpoint of MyWebService is located at http://localhost:7001/MyWebService, while the endpoint is configured as https://some-server:8011/external/MyWebService in the MyComposite_cfgplan_prod.xml config plan for the production environment.

Oracle Web Service Manager (OWSM) is used by Oracle SOA Suite to secure services, references, and components of an SCA composite. You can for example apply the out-of-the-box oracle/wss_username_token_client_policy enforcing a WSS UserName Token to be included in the invocation of an external Web Service. While there are numerous examples online that explain the use of config plans and other examples explaining design-time addition of OWSM policies using JDeveloper, there is less information on how to include and configure OWSM-specific settings in config plans for SOA Suite 11g.

Adding OWSM policies to an SCA composite at designtime in JDeveloper

Adding OWSM policies to an SCA composite at designtime in JDeveloper

OWSM policies can be applied and configured per reference, service, or component. When applying security to a reference and configuring it for a specific environment, the OWSM settings need to be placed as wsp:PolicyReference element between the attribute and property elements of the reference in the config plan. The wsp prefix refers to the http://schemas.oracle.com/ws/2006/01/policy namespace.

For example (snippet from a configuration plan):


<reference name="MyExternalService">
  <binding type="ws">
    <attribute name="location">
      <replace>http://server:8011/SomeService-1.3?wsdl</replace>
    </attribute>
    <wsp:PolicyReference 
      orawsp:category="security" 
      orawsp:status="disabled"    
      URI="oracle/wss_username_token_client_policy"/>
    <property name="csf-key">
      <replace>BPMS_USER</replace>
    </property>
  </binding>
</reference>


In the above example, the oracle/wss_username_token_client_policy is applied on the MyExternalService reference but disabled during deployment. It furthermore indicates that the credentials stored in the BPMS_USER key that is located on the server should be used in constructing the WS-Security UserName Token for the outbound SOAP call. While this may be an appropriate configuration for the test environment, for production you might want the policy to be enforced during deployment, perhaps use another policy that enforces SSL, and possibly use another CSF key. In order to do this, you can add these OWSM-specifics to the reference element in the configur plan for production.

For example (snippet from a configuration plan):

<reference name="MyExternalService">

  <binding type="ws">

    <attribute name="location">

      <replace>http://prodserver:8012/Service-1.3?wsdl</replace>

    </attribute>

    <wsp:PolicyReference 

      orawsp:category="security" 

      orawsp:status="enabled"    

      URI="oracle/wss_username_token_over_ssl_client_policy"/>

    <property name="csf-key">

      <replace>PROD_PROXY_USER</replace>

    </property>

  </binding>

</reference>