Introduction

Sometimes, using OSB, it may be necessary to attach credentials, such as username and password, on an outbound SOAP request to a remote server for authentication. While the OWSM policy store available with WebLogic Server provides policies that can inject username and password (e.g. “oracle/wss_username_token_over_ssl_client_policy”), OSB causes OWSM policies to be enforced on the outbound request message as well as the inbound response. This article will describe the steps to create the necessary WLS 9 policy and attach it to an OSB proxy service so that it is only enforced on the outbound request.

Consider the following business requirements:

1. Use OSB to communicate with an external Web Service over https.
2. The external Web Service requires authentication using a username and time-senstive, digested password in the HTTP header.
3. The external Web Service also requires a timestamp in the HTTP header.

Technology versions:

Oracle SOA Suite 11.1.1.7
Oracle Service Bus 11.1.1.7
WebLogic Server 10.3.6
Oracle Enterprise Pack for Eclipse 11gR1 (11.1.1.8)
WLS 9

Main Article

Summary of the steps to accomplish this task

Step 1. Enable PasswordDigest and https certificate exchange in WLS
Step 2. Create Custom Policy and ServiceAccount
Step 3. Attach the Policy and Service Account to the OSB Service

Step 1 Enable PasswordDigest and https certificate exchange in WLS

1. In the WLS Admin Console, navigate to Security Realms > myrealm > Providers > DefaultIdentityAsserter > Common
2. Shuttle “wsse:PasswordDigest” to “Chosen” in order to enable processing of Passwords using digest when a WLS 9 policy configured with PasswordDigest is used on an OSB service.
3. Shuttle “X.509” to “Chosen” in order to enable the server to authenticate other servers that identify themselves with certificates.

Note: The certificates will have to be imported into the server’s keystore if they are self-signed, or the CA is not recognized by the keystore (trust). For example:

From the keystore directory (e.g. c:\Oracle\Middleware\wlserver_10.3\server\lib), assuming the certificate is here as well:
keytool -import -trustcacerts -file myprivatecertname.pem -alias myprivatecertname -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

4. Still in the WLS Admin Console, navigate to Security Realms > myrealm > Providers > DefaultAuthenticator, check the “Enable Password Digests” checkbox, and click Save:

5. Restart the AdminServer as necessary.

Step 2 Create Custom Policy and ServiceAccount

Note: These instructions are for Eclipse, but the same process can be followed in the OSB Console.

1. Create a folder named ‘policy’ (this name is arbitrary) in the OSB Project to store the policy and service account.
2. Create a policy file by selecting the folder location and use the context menu > New > WS-Policy File:

3. Name the file: “wls9_username_token_digested_password_timestamp_client_policy”.
Paste the following into the contents of the file and save:

<wsp:Policy
	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
	xmlns:wssp="http://www.bea.com/wls90/security/policy"
	wsu:Id="wls9_username_token_digested_password_timestamp_client_policy">
	<wsp:ExactlyOne>
		<wsp:All>
			<!--  Identity Assertion -->
			<wssp:Identity>
				<wssp:SupportedTokens>
					<!-- Use UsernameToken for authentication -->
					<wssp:SecurityToken IncludeInMessage="true" TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken">
						<!-- Use a digested password -->
						<wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest"/>
					</wssp:SecurityToken>
				</wssp:SupportedTokens>
			</wssp:Identity>
			<!-- Timestamp -->
			<wssp:MessageAge Age="300"/>
		</wsp:All>
	</wsp:ExactlyOne>
</wsp:Policy>

4. Create a Service Account (these are the credentials the policy will inject into the SOAP header when calling the to remote web service) by right clicking the destination folder (can be same as location of policy file) > New > Service Account
5. Name the file, “ProtectedService-Credentials”, choose “Static”, and set the User Name and Password, and Save.

6. It is not preferable to store the password in a plaintext file, so an alternative to Step 5 would be to simply create this file directly in the OSB console after the OSB project has been deployed so that it is protected by authenticated access to the OSB console.

Step 3 Attach the Policy and Service Account to the OSB Service
1. Go to the Policy configuration tab of the Business Service
2. Select “From Pre-defined Policy or WS-Policy Resource” (we are using a WS-Policy Resource).
3. Select the “Request Policies” node under the appropriate operation, “process” in the case of this example (there may be more than one in your implementation, in which case, the following steps should be repeated for each operation).
4. Click “Add”. We are attaching it ONLY to the request and NOT to the response. This is the very reason we are using a WLS 9 policy attachment instead of using an OWSM policy attachment. OWSM currently only allows policies to be applied at the service level, meaning both the request and the response require the same policy enforcement.
5. Click the “Browse” button, select the policy created earlier, and click “OK”:

6. This is how it appears when you’ve successfully attached the policy:

7. Now that the policy is attached, we need to specify the username and password credentials to use when enforcing this policy. Click the “Security” tab, which will only be present after the Policy has been added.
8. Browse to the service account created earlier, “ProtectedService-Credentials”, and click “OK”:

Expected Result
Once you have deployed the OSB Proxy, you can test the service using the OSB Console or Soap client. If testing using the OSB Console, test directly against the business service so you can see the request before and after the policy is applied (see screenshot blew). If testing using another Soap client, be sure to enable tracing on the business service (where the policy is attached) and call the proxy end of the service. In the server log, you should now see the addition of a wsse:Security node in the soap:Header, and it should contain a UsernameToken and a Timestamp child elements. The UsernameToken should contain 3 child elements, Password (which should not be the plain text password), Nonce, and Created.

References:
Securing Oracle Service Bus with Oracle Web Services Manager
Using WS-Policy in Oracle Service Bus Proxy and Business Services

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission