OWSM and WS-Security: Username Token Authentication for SOAP and REST Services in OSB 12c.

This is the first time i write an English entry here in my blog, since it has been focused on a Spanish speaking audience, but this is an special occasion, yesterday I wrote a Spanish blog post in order to colaborate with OTN Appreciation Day, then a couple of friends ask me to translate and share it with them, so here we go now. I must apologize in advance with all of you for the Spanish images, i had no time to start all over again in English, I really hope you can guess the meaning of them, otherwise please contact me for the translation.

WS-Security is a specification published by OASIS, it is mainly aimed for SOAP Web Services. It encompasses a number of mechanisms to strengthen the integrity and confidentiality of the messages exchanged between these type of services such as data encryption, security tokens, username and password validation, signed messages, etc.

On the other hand, Oracle Web Service Manager (OWSM) is a component of Oracle SOA Suite that provides a framework for centralizing policy management and security of Web Services. OWSM is based on the WS-Policy standard and can be used in development time, or from the management console.

OWSM includes the following main elements:

• Policy Manager: Reads and writes policies, whether predefined or custom, to and from the repository.

• Agent: Executes policies and collects execution statistics. It has a cache memory for policies. It consists of a Policy Access Point (PAP) and a Policy Interceptor, the first communicates with the Policy Manager using EJB invocations, while the second is generated when a Web Service is deployed and activated, or when a policy is attached to a Web Service. Its functionality is to intercept requests to the Web Service and execute the policies associated with it.

• OWSM Repository: Place where policies are stored, typically a database.

• Enterprise Manager: Application where, in addition to managing several other elements,  the OWSM settings, metrics, etc. are configured.

In this article you will find how to configure from a development perspective using JDeveloper, a policy-based user and password authentication for a SOAP and a REST Web Service, based on the WS-Security specification using OWSM and OSB 12.2.1.

For the SOAP Service the username and password will travel in the UsernameToken element embedded within the SOAP Envelope message Header, and for the REST service, it will travel in the HTTP transport Header. And finally you can see how to test them using SOAPUI and POSTMAN.

The first step is to build and deploy a SOAP Proxy service in OSB, we will not develop it in this example, since it is not the main focus of this article, instead, we will use an existing service called PersonaSOAP.proxy. By accessing the WSDL URL we can see the definition of the service, which has a single operation and request and response headers.

Due to that this service is a mock service, and for this testing pourposes, it will always return a successful response. When executed in SOAPUI we can see the request and response messages.

To begin assigning the security policy, in JDeveloper edit the proxy service in the Policies tab. Initially it does not have any policies set.

Select From OWSM Policy Store radio button. Then, when the lower section of the screen is displayed, click on the symbol + in the Security section.

Select oracle/wss_username_token_service_policy from the list of predefined policies. OK to continue.

This is how the configuration must look like.

Save and redeploy the OSB project. Once deployed, re-check the url of the WSDL, this time you'll notice that some definitions of the security policies were added.

In order to test the service, you need to make sure you have installed OWSM and it is running. You can verify it in the Weblogic administration console, in the Environment, Servers section. This is where the list of servers in the domain is deployed, make sure that the WSM nodes are running, otherwise you can not use policies in runtime execution.

Once you're ready to test the service, you can do it with the client of your preference, in this case we will use SOAPUI, and to carry out this test it is necessary to configure the settings to add the user and password token within the Header element. In the lower section of the request message, click Auth and select Add New Authorization option.

Select Basic and clic OK.

Enter a valid user credential that was previously created in Weblogic.

If we test the service at this point, the result is an authorization error, because we have not added the Header with the user and password token yet.

To add this token to the request, right-click on the request message and select Add WSS Username Token option.

Select PasswordText and click OK.

You can see that the Security header in the Envelope Header element is added.

If we run the service test again, the user authentication will be performed and the message will reach its destination in OSB.

This simple test concludes the authentication policy configuration for SOAP messages. In case you need the user name and password not to travel in the header element of the Envelope message, but in the HTTP transport Header, you can select the wss_http_token_service_policy policy.

For example, in the case of a proxy REST Service, where there is no Envelope message, you can use this policy to send requests with user and password elements in HTTP Transport Header. The example settings are the ones shown below:

After deploying the service, you can test it with the REST client you prefer, in this example we will use POSTMAN. The request without authorization headers returns the following error:

In order to add the headers, clic on Authorization tab and select Basic Auth.

Enter a valid username and password, then click on Update Request button.

Notice that an encrypted value for the Authorization element was added in the Headers tab.

By submitting a new request, you will see that the security policy has been applied correctly and the response is successful.

Now you know how to add and test basic user and password authentication on both types of services, SOAP and REST, which are published in OSB, using default OWSM policies.