Invoking WS-Security compliant Web Services from Oracle BPEL

In last post I have discussed my experience on invoking Web Services using SSL from Oracle BPEL. SSL is a transport level security mechanism; it offers authentication, confidentiality and message integrity. It is one of the proven technologies to secure web applications. Various organizations leverage SSL to protect their web applications.

SOA applications are loosely coupled and composed with multiple services. SOA applications are discoverable from public registries. So securing SOA application is not only securing the transport layer. For a Business Process it might be required to invoke multiple intermediary services. Transport Layer Security can only guarantees security when data is on wires. SOA application security requires a mix of Transport Layer Security and Application-Level Security.

Nowadays many organizations are using Web Services to implement SOA. In Web Services world a lot of specifications are existed to address SOA security needs:

• WS-Security.

• WS-Addressing.

• WS-ReliableMessaging.

• WS-Policy.

• WS-SecurityPolicy.

• SAML.

• WS-Trust.

• WS-SecureConversation.

• WSFederation

In future posts I would discuss all the above mentioned standards in detail.

WS-Security specification provides extensions to the SOAP envelope header used to implement integrity and confidentiality of a message and authenticating the sender. WS-Security specifies how to associate a security token with a SOAP message. WS-Security specification is designed to be extensible. It doesn’t require any specific type of security token.

Oracle SOA Suite supports WS-Security specification. We can handle most of the complex SOA security scenarios using Oracle BPEL Process Manager and Oracle Web Service Manager.

“User Name Token” is a very common scenario to authenticate the web service consumer. It provides a standards-based way to send user credentials so that web services deployed on different platforms can share user credentials. It utilizes a message-based security approach moving credentials outside of the actual operation into SOAP headers without modifying the Web Service contract,

Let’s assume a WS-Security compliant Web Service is deployed on Axis2 and this method contains a method named getPrice(). To interact with this web service, you need to send SOAP messages containing valid WS-security credentials. We can convert any unsecured web service to a secured web service. No need to modify any web service to make it secure. The WS security specification plays with the soap headers rather than modifying the business logic or adding the authentication and authorization logic inside any service. It is the beauty of the WS-Security specification.

To pass security credentials from a BPEL process to another BPEL Process or any other web service it is required to set the following properties on the partner link which is used to invoke a WS Security compliant web service:

wsseHeaders Creates a WS-Security username token. The following values are supported:

• propagate — If the process has been invoked securely, these credentials are also used for the outbound direction

• credentials — Passes credentials from the BPEL deployment descriptor(bpel.xml).

wsseUsername The username for the token. It is a required property.

wssePassword The password for the token. It is an optional property.

Now you are ready to create a BPEL process in JDeveloper. Follow the given steps to create a BPEL Process:

• Create a new BPEL process project named “InvokeWSSecurityCompliantService“ with the Synchronous BPEL Process.

• Click on next and accept all the defaults and finish the wizard.

• Right click on the services area and choose “Create Partner Link” from the context menu.

• Name this partner link “WSSecurityCompliantServicePL”.

• Browse the WSDL file from the file system. JDeveloper would ask to make a local copy of the external WSDL file and ask to add partner link in the WSDL. Click on “Yes” on both the dialog boxes.

• Select Partner Link Type, Partner Role and click on the “Property” tab to provide WS security credentials.

• Click on “Create” and select “wsseHeaders” from the drop down list.

• You can use either “credentials” or “propagate” based on the requirement. If this BPEL process would be invoked by another process which is passing security credentials then you can use “propagate” to tell BPEL process manager to pass the incoming credentials to the service you are calling. You can use “credentials” as the property value to instruct BPEL Process Manager to read credentials from the deployment descriptor(bpel.xml).

• Create two new properties “wsseUsername” and “wssePassword” by following the same approach.

• Add “invoke” activity, name it as “InvokeSecuredWS” and link it with the partner link. Select the operation “getPrice” and create input and output variables.

• Add 2 assign activities to assign and transform the input and out variables. Final BPEL process will look like the following image:

• To deploy the BPEL process project on Oracle BPEL Process manager right click on the BPEL Process Project. From the context menu select “Deploy”, choose the appropriate integration server connection from the Deploy menu and select the appropriate domain.

• Test the BPEL process from the BPEL Console or from any client.

Now you are able to invoke WS-Security compliant web services. In next post I would throw some light on BEPL deployment descriptors configuration and preference properties. These properties play a crucial role in customizing BPEL processes as per our requirements.