OWSM SAML Policy Tests

This post assumes readers have the basic understanding of OWSM policy framework.

In this post, I’ll explore two examples of OWSM SAML policies. There are more than a dozen SAML policies that come with OWSM. One reason for the numerous SAML policies is OWSM provides two collections of SAML policies for WSS 1.0 (WS Security 1.0) and WSS 1.1. You can explore the difference between the WSS 1.0 and 1.1 that is outside the scope of this discussion. Suffice to say that when you pick policies on the client and service sides, you need to make sure that WSS versions match.

Nearly all of the OWSM SAML policies require some kind of encryption, except two wss10_saml(20)_token_service_policy. We will experiment with the non-encryption policy first, then we’ll discuss wss10_saml(20)_token_with_message_protection_service_policy.

For the experiments, I’ll create two local weblogic domains. “Domain 1” runs on port 7001. “Domain 2” runs on 7011. (Refer to previous post on how to createmultiple domains on your localhost).

For demonstration purpose, I use the following services:

•         A JavaEE web service – deployed to domain 2 and locked by a SAML security service policy
•         An OSB business service – on domain 1, it hooks up to the JavaEE web service. It has an attached SAML client policy.
•         OSB proxy service – on domain 1, locked up by WS name token security, which routes to the business service.

You can find jar files for these services here: javaEESvc and osb-config-jar. You can deploy OSB config jar to domain1, javaEESvc jar to domain2.

The steps below illustrate the test scenarios:

1.      use soap UI or other client tool to call the proxy service with ws name token header (with user name, password)

2.      OSB/OWSM authenticates the user. In this case, it uses Weblogic server’s default security realm. So you need to have a proper user defined with the Weblogic server. Proxy is invoked if the user authentication is successful.

3.      OWSM create a SAML assertion based on the authentication of step #2 above.

4.      OSB attaches the SAML assertion (user name only, no password) to the outbound business service call to the JavaEE service

5.      Weblogic/OWSM authenticates the web service call with SAML header. In this case, the authentication only verifies the user name exists in the security realm. The password doesn’t matter. If the authentication is successful, the JavaEE service is invoked.

6.      JavaEE service response is routed back to SoapUI (via business service and proxy service)

WSDL

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"

  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://tempuri.org/"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

  name="samlPocService" targetNamespace="http://tempuri.org/">

  <types>

    <xs:schema xmlns:tns="http://tempuri.org/" xmlns:xs="http://www.w3.org/2001/XMLSchema"

      version="1.0" targetNamespace="http://tempuri.org/">

      <xs:element name="sayHello" type="tns:sayHello" />

      <xs:element name="sayHelloResponse" type="tns:sayHelloResponse" />

      <xs:complexType name="sayHello">

        <xs:sequence>

          <xs:element name="arg0" type="xs:string" minOccurs="0" />

        </xs:sequence>

      </xs:complexType>

      <xs:complexType name="sayHelloResponse">

        <xs:sequence>

          <xs:element name="return" type="xs:string" minOccurs="0" />

        </xs:sequence>

      </xs:complexType>

    </xs:schema>

  </types>

  <message name="sayHello">

    <part name="parameters" element="tns:sayHello" />

  </message>

  <message name="sayHelloResponse">

    <part name="parameters" element="tns:sayHelloResponse" />

  </message>

  <portType name="samlPoc">

    <operation name="sayHello">

      <input message="tns:sayHello" />

      <output message="tns:sayHelloResponse" />

    </operation>

  </portType>

  <binding name="samlPocPortBinding" type="tns:samlPoc">

    <soap:binding style="document"

      transport="http://schemas.xmlsoap.org/soap/http" />

    <operation name="sayHello">

      <soap:operation soapAction="" />

      <input>

        <soap:body use="literal" />

      </input>

      <output>

        <soap:body use="literal" />

      </output>

    </operation>

  </binding>

  <service name="samlPocService">

    <port name="samlPocPort" binding="tns:samlPocPortBinding">

      <soap:address location="http://localhost:7011/javaeesvc/samlPocPort" />

    </port>

  </service>

</definitions>

JavaEE service:

It’s a no thrill simple hello world java function:

package javaeesvc;

import javax.jws.WebService;

@WebService(targetNamespace = "http://tempuri.org/")

public class samlPoc {

    public samlPoc() { super(); }   

    public String sayHello(String s) {

        System.out.println("######Hello " + s + ", this is saml poc");

        return "######Hello " + s + ", this is saml poc";

    }

}

JavaEE service is deployed to domain 2:

Biz Service Configuration, no policy attached yet:

Proxy service:

Then attach WS name token policy to the proxy

Experiment 1 – SAML Policy without Encryption

Testing “oracle/wss10_saml20_token_client_policy”

In this experiment, we’ll demonstrate the SAML policy without encryption (plain SAML policies). Without encryption, there will be no additional server configurations involved.  You can merely attach the corresponding SAML policies on both the JavaEE service and OSB business service, that’s it.

In the next section we’ll see when message protection (encryption) is involved, it becomes a different ball game. You need to configure quite a few things before SAML policies can work.

Let’s do the simple one first.

Attach SAML policy to JavaEE service:

Under “Web Service Endpoints” tab, click on endpoint name “samlPocPort”:

Click on “Attach/Detach” icon:

Select “wss10_saml20_token_service_policy” then press “Attach”

Attach SAML policy to OSB business service:

SOAP UI client test:

What has happened?

Part 1: Soap UI calls Proxy Service with WSS name token

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

  xmlns:tem="http://tempuri.org/">

  <soapenv:Header>

    <wsse:Security soapenv:mustUnderstand="1"

      xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

      <wsse:UsernameToken wsu:Id="UsernameToken-2"

        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

        <wsse:Username>weblogic</wsse:Username>

        <wsse:Password

          Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcome1

</wsse:Password>

      </wsse:UsernameToken>

    </wsse:Security>

  </soapenv:Header>

  <soapenv:Body>

    <tem:sayHello>

      <arg0>soupui</arg0>

    </tem:sayHello>

  </soapenv:Body>

</soapenv:Envelope>

Part 2: Business Service Invokes JavaEE service with SAML token

Internally, OWSM first authenticates user “weblogic” with password, then it generate SAML token (assertion). OSB business service attaches the SAML assertion in the header. Business service calls JavaEE service with the SAML assertion.

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

  <wsse:Security soapenv:mustUnderstand="1"

    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

    <saml:Assertion MajorVersion="1" MinorVersion="1"

      AssertionID="SAML-xnTew5qgIPuu2kkZGcVqhQ22" IssueInstant="2013-07-29T22:26:43Z"

      Issuer="www.oracle.com" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

      <saml:Conditions NotBefore="2013-07-29T22:26:43Z"

        NotOnOrAfter="2013-07-29T22:31:43Z" />

      <saml:AuthenticationStatement

        AuthenticationInstant="2013-07-29T22:26:43Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">

        <saml:Subject>

          <saml:NameIdentifier

            Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">weblogic</saml:NameIdentifier>

          <saml:SubjectConfirmation>

            <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches

            </saml:ConfirmationMethod>

          </saml:SubjectConfirmation>

        </saml:Subject>

      </saml:AuthenticationStatement>

    </saml:Assertion>

  </wsse:Security>

</soap:Header>

<soapenv:Body>

  <urn:sayHello xmlns:urn="urn:examples:helloservice">

    <firstName xsi:type="xs:string" .>test</firstName>

  </urn:sayHello>

</soapenv:Body>

</soapenv:Envelope>

In case anyone wonders how I captured the SAML payload, I used TCPMon tool to trap the business outbound call. With OSB 11.1.1.6 version, you can also see similar payload using the OSB business service test console.

The main take away in this experiment is that OSB business service calls JavaEE with SAML assertion and user name, but no password is provided. JavaEE service is configured with a plain SAML token policy that blindly trusts anyone with a well formatted SAML token, as long as the user name exists in “Domain 2”. The web service request will be accepted.

Well, if you find this behavior questionable, then you are correct. Oracle doesn’t recommend using this “plain” dumb SAML policy. In next section, we’ll test with a SAML policy that requires “message protection”. i.e. payload will be encrypted with key (certificate), so the service requests (from the client) can be trusted with assurance by the web service (server).

SAML policy with message protection (encryption)

We’ll use wss11_saml20_token_with_message_protection_client_policy for our experiment.

This SAML policy requires the payload be encrypted (message protection). As far as OWSM policy configurations are concerned, there is not much difference between this policy and the plain SAML policy we discussed earlier. However, there are major configuration steps involved to setup the domains for the encryption/decryption to work.

Setting up certificate trusts between the two domains

If you never worked with OWSM key stores, it can be a daunting task to go through the steps in this section for the first time. You can reference this previous post to get familiar with the OWSM key stores.

By default, the key store is here {domain_home}/config/fmwconfig/default-keystore.jks. The actual key store location is specified in this file {domain_home}/config/fmwconfig/jps-config.xml

In order for message encryption/decryption to work, the two domains need to exchange their keys. “Domain 2” will import the public key of “Domain 1”. So when “domain 1” sends an encrypted message (encrypted with Domain 1’s private key), “domain 2” will be able to decrypt the message with “domain 1’s” public key. Vice versa, “domain 1” needs to import the public key of “domain 1”.

Here are the keytool commands to generate keys for each domain, and to import the public keys to each other’s key store.

 

  #### generate default keypair for domain1, valid for 10 years

  keytool -genkeypair -alias d1key  -keyalg RSA -keypass d1pass -keystore domain1-keystore.jks  -storepass welcome1 -validity 3650

  #### generate default keys for domain2, valid for 10 years

  keytool -genkeypair -alias d2key  -keyalg RSA -keypass d2pass -keystore domain2-keystore.jks  -storepass welcome2 -validity 3650

  #### list key stores

  keytool -list -v -storepass welcome1 -keystore domain1-keystore.jks

  keytool -list -v -storepass welcome2 -keystore domain2-keystore.jks

  #### export domain1 public key

  keytool -exportcert -alias d1key -storepass welcome1 -keystore domain1-keystore.jks -file domain1-pubkey.cer

  #### export domain1 public key

  keytool -exportcert -alias d2key -storepass welcome2 -keystore domain2-keystore.jks -file domain2-pubkey.cer

  #### import domain2 public key into domain 1 as "d2impkey"

  keytool -importcert -alias d2impkey -storepass welcome1 -keystore domain1-keystore.jks  -file domain2-pubkey.cer

  #### import domain1 public key into domain 2 as "d1impkey"

  keytool -importcert -alias d1impkey -storepass welcome2 -keystore domain2-keystore.jks  -file domain1-pubkey.cer

  ### if you need to remove a key

  keytool -delete  -alias yourkey  -keystore keystore.jks -storepass welcome1

The screen below shows how to configure the key store for domain 1. Pay close attention to each field in this screenshot and notice how the field values correspond to the values we used in the key commands above. You will need to bounce the servers if you change key store files. Remember the default is default-keystore.jks, which is specified in jps-config.xml.

This screen shows how to configure the key store for domain 1.

Once the OWSM key stores are configured for both domains. You will detach the plain SAML policies from javaEESvc on domain 2 and the business service on domain 1. Then reattach wss10_saml20_token_with_message_protection_service_policy to JavaEESvc, and wss10_saml20_token_with_message_protection_client_policy to the OSB business service.

You also need to configure the security property on the business service as shown below.The recipient alias is the domain 2 public key. We imported into domain 1 with the alias "d2impkey". This key will be actually used to decrypt the response message from domain 2, which is encrypted with domain's private key.

This screen shows how to configure the business service “security” tab:

You will need to configure domain 2 OWSM key store similarly.

Test in OSB console

If everything is configured correctly, you can test the business service from the OSB console (works for OSB 11.1.1.6, may not work for earlier version)

The test console shows data is encrypted:

Test with SoapUI

The SoapUI test will show the same thing either SAML policy is encrypted or not encrypted.
Final notes:
I used OSB and JavaEE service for the experiments. You can also use SOA composite to test the SAML policies. It is recommended to use JDeveloper to attach policies to SOA composite, but you can also use "em" console to the same.