Using Identity Switching from SOA Suite

My requirement for Identity Switching came when I was implementing a BPM process. We had a process where a user would initiate a simple process and attach a relevant document. This document then needed to be checked in to UCM using the provided web service.

The original setup had the BPM process authenticating as a system user when calling the UCM web service, regardless of which user actually approved the task. This worked, but meant that every document appeared to be checked in as that system user, and not as the user who actually uploaded the document.

The solution to this problem was to use Identity Switching to effectively authenticate as one user, but then switch the SAML token that is actually used when calling the UCM Web Service.

This blog post uses the UCM Web Service as an example, but can be applied to any web service that has the oracle/wss11_saml_token_with_message_protection_service_policy applied to it. For instructions on how to do apply this policy to the UCM (or another) web service, see Securing a Web Service on WebLogic

Setting Up the JDeveloper Project

The first step is to create an empty JDeveloper SOA Application/Project:

1. Open JDeveloper and select File->New->SOA Application
2. Enter an Application Name and click Next
3. Enter a Project Name and click Next
4. Select Empty Composite and click Finish

Adding the External Web Service

Now that you have your empty composite you want to add the Web Service. To do this, first open the the composite.xml file then drag a Web Service adapter from the Component Palette onto the External References right-hand column. You will be prompted to enter your web service details. I have used the UCM Web Service:

Option 1 - Identity Switching Using Mediator

I find the Mediator is simpler to implement and makes more sense if all you are doing is simply setting up Identity Switching.

For a Mediator, drag the Mediator Service Component from the Component Palette onto the Components central column of the composite.xml. I have set up my Mediator to be based off of the same WSDL as the Web Service to keep things simple. See below for details:

Connect the Mediator to the Web Service on the composite.xml.

Because the composite input is the same type as the web sevrice input, the Mediator implemntation is complete. If you used a different input schema for your Mediator, you will most likely need transform your Mediator and Web Service inputs and outputs.

The only step left is to set up the actual Identity Switching in the mediator:

1. Open the Mediator
2. Under the Static Routing click the button beside the first Assign Values field for the request
3. Click the Add (plus) button
4. In the From column, select constant from the drop down
5. Enter the username of the user whose identity you want to switch to e.g. usera
6. In the To column, select property from the drop down
7. From the list of available property values, select javax.xml.ws.security.auth.username
8. Click OK
9. Save all files

Below are my Routing Rules after implementing the Mediator:

Option 2 - Identity Switching Using BPEL

Identity Switching can also be implemented using a BPEL Process which can be useful if you are trying to achieve more than Identity Switching in your Composite.

For a BPEL Process, drag the BPEL Process Service Component from the Component Palette onto the Components central column of the composite.xml. I have set up my BPEL Process to be based off of the same WSDL as the Web Service to keep things simple. See below for details:

Connect the BPEL Process to the Web Service on the composite.xml.

The BPEL Process does not automatically map between the process and Web Service input/output. As such you will need to add:

1. An Invoke which connects to your Web Service
2. A Transform (or Assign) to map the BPEL process input to the Web Service input
3. A Transform (or Assign) to map the Web Service output to the BPEL process output

The BPEL process should resemble that below:

The final steps are to perform the actual Identity Switching on the BPEL Invoke:

1. Open the BPEL Process
2. Double Click the Invoke and select the Properties tab
3. Locate the property named javax.xml.ws.security.auth.username
4. In the Value column, click the "..." lookup button
5. Select the Expression radio button and enter the username string of the user whose identity you want to switch to e.g. 'usera'
6. Click OK twice
7. Save all files

Securing the Endpoints

At this point, all of the relevant service endpoints have been added to the composite.xml, so we are ready to set their security. For this example, the composite will require a simple username/password token, and will use this token to authenticate against the UCM web service, but switch the Identity.

The first step is to setup the UCM web service for Identity Switching:

1. Right click on the Web Service under External References and select Configure WS Policies...
2. Click the Add button beside the Security heading
3. Select oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy
4. Click OK to both popups
5. Save All files

Next, set the security for the endpoint of our BPEL/Mediator:

1. Right click on the Exposed Service and click Configure WS Policies...
2. Click the Add button beside the Security heading
3. Select oracle/wss_username_token_service_policy
4. Click OK to both popups
5. Save All files

Adding System Policies

Before a SOA Composite can use Identity Switching, it must be given explicit permission. The easiest way to do this is to log on to Enterprise Manager, right click on your domain and select Security ->System Policies:

From the System Policies screen:

1. Click the Create... button.
2. Enter a Code Base of file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar
3. Click the Add button under Permissions
4. Check the Select here to enter details for a new permission checkbox
5. Enter the following details:
   • Permission Class: oracle.wsm.security.WSIdentityPermission
   • Resource Name: *
   • Permission Actions: assert
6. Click OK twice to save your changes

You can also use the following WLST command to create the same System Policy as above:

grantPermission(codeBaseURL='file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar', permClass="oracle.wsm.security.WSIdentityPermission", permTarget="resource=*", permActions="assert")

NOTE: The value for Resource Name above should ideally be the name (and version) of your particular composite e.g. IdentitySwitchingComposite[1.0]. However, I could not seem to get this working correctly, so took the easy way out and entered "*", so that all composite would be granted access to perform Identity Switching.

Testing Identity Switching

Now that your Composite has been developed and the necessary System Policies have been created, you can finally deploy your Composite for testing. To test I call my Composite passing in the credentials of userb but the update of metadata in UCM is recorded against usera