WS-Security interoperability with Oracle BPEL and WSE 3.0

By Jesus Rodriguez

Oracle BPEL Process Manager & Security

With each release, BPEL is emerging more and more as the declarative standard to describe business process based on web service interactions. Additionally, during the last few years, WS-* protocols have been created to improve the web service basic stack (SOAP, WSDL, UDDI) in different areas like security, reliable messaging and metadata management. Security has been of particular focus in regards to protocols such as WS-security, WS-secure conversation and WS-trust. The ability of BPEL-based process to interact with web services that express those protocols as part of their contract will become more critical every day. Alternatively, interoperability between the different implementation of WS-security, mainly between the J2EE and .NET platforms, is a key aspect of the realization of SOA.

Oracle BPEL Process Manager provides an extensive set of features around web service security. Its combination with the Oracle Web Services Manager (formerly OBLIX) can address some of the most complex web services-security scenarios.

This article explores the development of Oracle BPEL Processes that interact with .NET web services using WS-security.      For the purpose of this scenario, we are using web services Enhancements 3.0 on the .NET platform.

What is WS-security?

WS-security is the main specification to enable security in web services. It addresses scenarios like message integrity, authentication and message confidentiality.

WS-Security 1.1 was recently approved as an OASIS Standard.

Is there something wrong with SSL?

Message Security vs. Transport Security

SSL has proven its effectiveness in securing resources through the Internet. When dealing with web services however, SSL must be considered in conjunction with WS-security to provide a truly secure environment.

  • SSL is strictly tied to TCP-based transports like HTTP, for web services that are using non-TCP transports such as MSMQ or SMTP SSL, which does not represent a viable option.
  • SSL was designed for point-to-point communications; making it difficult to implements in a routing scenario between web services. In a routing scenario, the final receiver must be able to validate the original credentials.  Extensibility using SSL becomes difficult to provide when those credentials are not stored in the message.
  • SSL protects the messages on the wire (between the endpoints) but does not provide protection for the message on the endpoints; allowing access to the whole message upon gaining access to one of the endpoints.

Authentication with UserNameToken

Authentication with UserNameToken is arguably, the most common scenario when referencing authentication.  The web service consumer authenticates to the web service using a Username and Password pair.

The WS-security UserNameToken profile provides a standards-based way to send user credentials so that applications and platforms can unify their approach. It utilizes a message-based security approach moving credentials outside of the actual operation into SOAP headers, making it possible to alter authentication without touching the operation.

WS-Security Authentication from Oracle BPEL Process Manager to WSE

In the following example we use a .NET-based web services capable of performing the complex mathematical operation of adding two numbers. The .NET interface code for the service is displayed below.

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[Policy("SamplePolicy")]

public class MathService_ASPNet : System.Web.Services.WebService

{

                      public MathService_ASPNet()

                      {

 

                                                //Uncomment the following line if using designed components

                                                //InitializeComponent();

                      }

 

                      [WebMethod()]

                    public int Add(int param1, int param2)

                      {

                                                return param1 + param2;

                      } 

}

 WSE provides two ways to express WS-security; imperatively using code and declaratively using WS-policy. I prefer declarative languages, so we will use the following WS-policy assertion to secure the web service using UserNameToken profile. 

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">

        <extensions>

                      <extension name="usernameOverTransportSecurity" type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

                      <extension name="username" type="Microsoft.Web.Services3.Design.UsernameTokenProvider, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

                      <extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

                 <extension name="authorization" type="Microsoft.Web.Services3.Design.AuthorizationAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

        </extensions>

        <policy name="k">

                      <usernameOverTransportSecurity />

        </policy>

</policies>

 To link the WS-policy with web service we must add the following code to the web.config file.

…

<webServices>

                                  <soapExtensionImporterTypes>

                                                <add type="Microsoft.Web.Services3.Description.WseExtensionImporter, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

                                  </soapExtensionImporterTypes>

                                  <soapServerProtocolFactory type="Microsoft.Web.Services3.WseProtocolFactory, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

                      </webServices>

        </system.web>

        <microsoft.web.services3>

                      <security>

                                  <securityTokenManager>

                                         <add type="InteropSamples.CustomUserManager.CustomUsernameTokenManager,SampleBase" namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" localName="UsernameToken" />

                              </securityTokenManager>

                  </security>

                      <policy fileName="wse3policyCache.config" />

…

 As you can see in the configuration file, this example uses a custom security token manager to validate credentials. The AuthenticateToken method of the token manager is invoked to validate credentials. Our web service only authenticates the user “ok” with password “ko” seen in the following code.

protected override string AuthenticateToken( UsernameToken token )

     {

                        

                                                                          if (token.Username == "ok")

                                                                                                    return "ko";

     }

 To interact with web service, clients must send SOAP messages containing valid WS-security credentials.  The following is an example of valid WS-security credentials.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" >

        <soap:Header>

                      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

                              <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-941458a9-6eff-4bc7-9d56-c6833ff249d4">

                                         <wsse:Username>ok</wsse:Username>

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

                                         <wsse:Nonce>yHOCbdMAoejJz8l1PDi3Fw==</wsse:Nonce>

                                         <wsu:Created>2006-02-18T15:52:32Z</wsu:Created>

                              </wsse:UsernameToken>

                  </wsse:Security>

        </soap:Header>

        <soap:Body>

                      <Add xmlns="http://tempuri.org/">

                                  <param1>12</param1>

                                  <param2>23</param2>

                      </Add>

        </soap:Body>

</soap:Envelope>

 

Now that we understand WS-policy and WS-security, we can explore how to create an Oracle BPEL Process Manager Process that invokes this web services.     For this example we are using Oracle JDeveloper as a host for the BPEL designer. The following figure represents a view of our process in the BPEL designer.

Figure 1: Process representation in the Oracle BPEL Process designer.

The first required step is to create a BPEL partner link that represents the WSE web service. The following code represents the partner link declaration.

<plnk:partnerLinkType name="ServiceSoap_PL">

        <plnk:role name="ServiceSoap_Role">

                      <plnk:portType name="tns:MathService_ASPNetSoap"/>

        </plnk:role>

</plnk:partnerLinkType>

 

The next step is to provide the required WS-security headers as part of the invoked activity. Using bpelx:inputHeaderVariable we can pass SOAP headers as part of the invoked activity. This is the primary artifact we will use to send the WS-security SOAP headers. Oracle BPEL Process Manager v10.1.2 also provides deployment descriptor properties (wsseHeaders, wsseUsername, wssePassword) to handle WS-security headers specifically related to the UserNameToken profile. The following example highlights the BPEL fragments dealing with WS-security headers.

<process name="InteropPrj" targetNamespace="http://xmlns.oracle.com/InteropPrj" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns1="http://tempuri.org/" xmlns:ldap="http://schemas.oracle.com/xpath/extension/ldap" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:client="http://xmlns.oracle.com/InteropPrj" xmlns:bpelx="http://schemas.oracle.com/bpel/extension" xmlns:ora="http://schemas.oracle.com/xpath/extension" xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc">

 

        <partnerLinks>

                      <partnerLink name="client" partnerLinkType="client:InteropPrj" myRole="InteropPrjProvider"/>

                      <partnerLink name="SecureSrv" partnerRole="ServiceSoap_Role" partnerLinkType="ns1:ServiceSoap_PL"/>

        </partnerLinks>

 

        <variables>

                      <!-- Reference to the message passed as input during initiation -->

                      <variable name="inputVariable" messageType="client:InteropPrjRequestMessage"/>

                      <!-- 

                      Reference to the message that will be returned to the requester

                      -->

                      <variable name="outputVariable" messageType="client:InteropPrjResponseMessage"/>

                      <variable name="msgIn" messageType="ns1:AddSoapIn"/>

                      <variable name="msgout" messageType="ns1:AddSoapOut"/>

                      <variable name="wscheaders" element="ns4:Security"/>

        </variables>

 

        <sequence name="main">

        .... Receive steps

                      <assign name="Assign_1">

                                  ...Copy Rules

                                  <copy>

                                         <from>

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

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

                                                                                      <wsse:Username>

                                                                                                    ok

                                                                                      </wsse:Username>

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

                                                                                                    ko

                                                                                      </wsse:Password>

                                                                          </wsse:UsernameToken>

                                                            </wsse:Security>

                                         </from>

                                         <to variable="wscheaders"/>

                                  </copy>

                      </assign>

                      <invoke name="Invoke_1" partnerLink="SecureSrv" portType="ns1:MathService_ASPNetSoap" operation="Add" inputVariable="msgIn" outputVariable="msgout" bpelx:inputHeaderVariable="wscheaders"/>

                      ...Final steps

        </sequence>

</process>

    

Where are we?

We have explored the outbound WS-security interoperability between Oracle BPEL Process Manager and WSE 3.0.  We can conclude that Oracle BPEL manager provides robust support for SOAP Headers that allows interaction with web services that implements WS-* protocols.      I believe the next step in Oracle BPEL Manager must be oriented to provide declarative support to all the features of WS-security as well as other WS-* protocols like WS-trust and WS-secure conversation that guarantees interoperability with the most notables web service platforms in the market.

1 Comment

  • Any pointers on how to call a .Net web service from Oracle BPEL when the .Net web service is hosted on IIS 6, is secured with Basic Authentication, and must be called via HTTPS?

Comments have been disabled for this content.