Securing Heterogeneous Systems Using Oracle Web Services Manager

by Ronald van Luttikhuizen and Jens Peters

A case study on using Oracle Web Services Manager to secure interactions between Web Services exposed by Oracle Service Bus and an employee portal built in Microsoft .NET and Silverlight.

Downloads
download-icon13-1 Oracle Web Services Manager
download-icon13-1 Oracle Service Bus
 

Remember the time when Web Services were new and exciting? They were taking off by promising to provide "true" interoperability and independence from underlying platforms and toolsets. In those days vendors introduced tooling to create and consume Web Services while several WS-* standards were not yet fully matured. No wonder that true interoperability was not achieved right away. Integrating a plain-old Web Service in which the client used the same toolset as the provider was rarely problematic. But trying to consume a Web Service generated in a completely different technology than the client could be a nightmare, especially when one or more WS-* standards, such as WS-Security, were applied.

We have seen our share of Java Web Services that could not be easily integrated with .NET clients, and vice versa, due to different interpretations of standards, different supported versions of standards, different encodings, and so on. One remedy was to build either the provider or consumer of the Web Service by hand instead of using tools that generated Web Service artefacts, thereby defeating the purpose of the added-value that standards bring: ease and speed of development supported by tools. Luckily WS-* standards, conformance tests such as WS-Interoperability, and toolsets matured over time. Today the promise of true interoperability is much more realistic than it was five or ten years ago.

In this article we will investigate a case-study in which an employee portal application built on the Microsoft .NET framework and Silverlight consumes Web Services that are exposed by the Oracle Service Bus (OSB). Needless to say, this scenario involves Web Service interactions between two completely different toolsets. The article describes how to achieve first contact between these toolsets, how to use Oracle Web Services Manager (OWSM) to secure the exposed Web Services in a declarative way, and how the portal application interacts with these secured services.

Case Study

The case study is based on a public sector project in the Netherlands. The main goal of this project is to increase flexibility and agility in the organization's IT landscape, thereby simplifying future changes in both the organization and its IT systems. This goal, among others, is achieved by gradually transforming the application landscape from a collection of siloed applications that "do a bit of everything" to a landscape of reusable, easily integrated building blocks (or services), each with a clear and specific purpose. These building blocks can be new commercial off-the-shelve (COTS) components, new custom developed services, or existing components.

A simplified overview of the new application landscape and its components is shown in Figure 1. The functionalities of the backend systems (yellow) are exposed as Web Services using Oracle Service Bus (blue), whereby underlying specifics such as proprietary protocols and data formats are "hidden" by the bus. Examples of these generic building blocks include:

  • A Document Service, virtualizing two existing Document Management Systems
  • A Case Management Service that exposes the functionality of a Case Management System
  • Financial Services
  • CRM functionality that can be accessed through the Customer Service.

The exposed services are consumed and reused by redesigned business processes, such as the grants and permits processes that are implemented using Oracle SOA Suite (red), and a portal application used by employees to support the organization's business processes. The portal is built in Microsoft .NET and Silverlight (green).


osb-silverlight-oswm-fig01
Figure 1

Future systems such as a web based Customer Portal and other business processes should reuse the same services. It is not yet known what the underlying technology of these systems will be, so it is vital that the services are interoperable and provide good quality-of-service, including adequate security.

Security

Many things can be said of siloed and monolithic systems: they can be hard to change, difficult to administer, complex to analyze, and troublesome to integrate and reuse. However, combining all data and functionality into one big monolithic system can be easy from a security viewpoint. Data and functionality are located in one place. If you secure such a system effectively, your data is protected and functionality is secured. In SOA environments data and functionality are divided in different smaller chunks that themselves are simple, flexible, and can be easily changed and integrated. As a side-effect, more messages will flow between your services and in and out of your organization than is the case for a landscape consisting of only a few monolithic applications. This requires a different view on security. The following concrete aspects of service-orientation can have impact on security:

  • Increased amount of machine-to-machine interactions as compared to human-machine interactions. Automated interactions also require security mechanisms such as authentication to be automated.
  • There are more intermediate components -- such as ESBs, agents, and routing services -- involved in message exchanges between the initial and final recipient of messages. These intermediaries may not operate on these message or may not be allowed to view or change inflight messages. Information needs to be secured "in rest" in addition to being secured solely during transport.
  • Reusable services can have lots of consumers, both within and outside your own organization. We need to determine if consumers are allowed access to data and functionality exposed by a service, and we must be able to differentiate access control between the various consumers.
  • There will be more straight-through-processing in which a whole process or large parts of it are fully automated without any human intervention. Consequences of faults may be detected fairly late because of the higher degree of automation, with significant repercussions due to the higher volume of processed messages, thereby increasing the need for good security and management.
  • Increased use of external services in which security is largely outside your immediate control, for example, when consuming Cloud-based services over the Internet. Conversely, your services can be consumed by external organizations. Your services will only be used if consumers have faith in their quality-of-service, including their security.
  • Chances are that not all services an organization uses are built in the same technology. Together with the higher degree of integration between services this requires implementation-neutral security standards. Security implementations should adhere to these standards.

Security in IT systems is often implemented on the transport or application layer. Examples of transport security mechanisms include the use of SSL (or TLS) to encrypt and sign messages in transit and to enforce authentication — using 2-way SSL, for example. The downside of using transport-level security alone is that "data in rest" is not secured. This can be the case for messages that are handled in intermediary components such as ESB and BPM platforms. When using message-level security, the messages themselves are encrypted, signed, and can contain authentication and authorization information. In these cases data can also be secured while being stored or processed in these intermediaries. Numerous articles and books discuss transport- and message-level security, so we will skip a deep-dive into those mechanisms in this article.

Oracle Web Services Manager

Oracle Web Services Manager (OWSM) provides a policy (or agent) based security framework to implement security requirements for services. This means that security functionality is declaratively added to service providers and clients without the need for custom coding and deployment. OWSM provides dozens of out-of-the-box policies for most of the common security requirements. These policies are divided into the following categories:

  • reliable messaging
  • management
  • addressing
  • security
  • Message Transmission Optimization Mechanism (MTOM).

The functionality offered by those policies includes:

  • Authentication using WS-Security Username Token,
  • Encrypting and signing messages using WS-Security standards and PKI certificates,
  • Adding WS-Addressing information to request and response messages,
  • Logging inbound and outbound messages.

See Security and Administrator's Guide for Web Services for a list of all supported policies.

OWSM implements security mostly on the message-level; transport-level security can be implemented using the SSL support in Oracle WebLogic Server, on which OWSM and the services run.

Adding and configuring policies can be done at design time using Oracle JDeveloper or Oracle Enterprise Pack for Eclipse as well as at runtime through Oracle Enterprise Manager or Oracle Service Bus Console. Oracle Enterprise Manager can be used to monitor policies and inspect violations of these policies — for example, when wrong username/password combinations are used. The policies can be applied to different service implementations, such as SOA composites, OSB Services, and plain JAX-WS Web Services that run on Oracle WebLogic Server.

Figure 2 depicts the DocumentService again and the employee portal invoking the service. This time, however, the service is secured using the out-of-the-box oracle/wss_username_token_service_policy policy enforcing authentication based on a WS-Security Username Token. The oracle/log_policy policy is applied to log all request and response messages sent to the DocumentService for audit purposes. The implementation of the DocumentService remains unchanged; policies are applied by configuration. The consumer is unaware of (the details of) these policies.


osb-silverlight-oswm-fig02
Figure 2

As you can see, policies can be chained to fulfill more complex security requirements. OWSM also provides an extension mechanism to develop custom policies in Java in case the out-of-the-box policies are insufficient.

OWSM is integrated into Oracle WebLogic Server and uses the security APIs offered by that platform. That means, among other things, OWSM can delegate authentication and authorization to WebLogic's configured authentication provider, such as Oracle Internet Directory (OID), Oracle Access Manager, or any other LDAP-compliant product.

Implementing Security in the Case Study

Let's take another look at the case study. The following security requirements are identified for the interactions between the portal and the exposed services:

  • Not everyone should be able to create and approve grants by directly invoking the backend services. Authentication needs to be enforced to avoid unauthorized access to the Web Services and the underlying functionality. Authentication should be delegated to an existing OID.
  • Intercepted messages that are transmitted between the portal and OSB should be confidential since they contain sensitive data, such as personal information about applicants. We need to add confidentiality so that intercepted messages are protected.

These requirements can be satisfied using either transport- or message-level security. In this example a WS-Security Username Token will be used for authentication, and SSL for confidentiality on transport level.

The next sections of this article show how to use OWSM to secure a Web Service and how to invoke such a secured service from an application developed in Microsoft Silverlight.

Implementation

The "HelloWorld" demo showing the case consists of the following steps that will be explained in the following sections:

  1. Secure OSB services
    1. Enable SSL on WebLogic Server
    2. Apply OWSM policies
    3. Authentication provider
    4. Test secured services with soapUI
  2. Add security configuration to a Silverlight client
    1. Introduction to Silverlight
    2. Gaining access to a cross domain Web Service from Silverlight
    3. SSL pitfalls
    4. Implementing WS Security in Silverlight

Secure OSB Services

This section explains how to enable SSL on the Managed Server on which OSB runs and lists the steps to apply OWSM policies using the Oracle Service Bus Console.

Enable SSL on WebLogic Server

Since we need to implement transport-level security we have to make sure the Managed Server supports SSL.

  1. Login to the Oracle WebLogic Administration Console to enable SSL and to assign the SSL Listen Port.
  2. Navigate to Environment Servers, select the Managed Server, and enable the SSL Listen Port Enabled checkbox. If you want, you can change the default SSL listen port.

osb-silverlight-oswm-fig03 
Figure 3

Note that Oracle WebLogic Server uses its demo identity and trust store and the keys and certificates it contains by default for 1-way and 2-way SSL. For production purposes it is best to replace the demo stores with "real" keystores that contain keys and certificates issued by trusted certificate authorities instead of self-signed certificates.

Apply OWSM Policies

A prerequisite for using OWSM in conjunction with OSB is to install and configure OSB in an Oracle WebLogic Domain including OWSM and MDS. Applying OSWM policies on OSB-exposed Web Services is rather trivial using either OEPE (designtime) or the Service Bus Console (runtime). In this case we use the runtime console.

  1. Login to the console, navigate to the Policies section of the Proxy Service you want to secure, and select the oracle/wss_username_token_service_policy policy. This policy will enforce SSL (for message confidentiality) and authentication through a WS-Security Username Token.

    Note that SSL is configured on the Oracle WebLogic Server level; the policy however verifies that messages are sent to OSB over SSL.

osb-silverlight-oswm-fig04
Figure 4

  1. Once the policy is set we need to enable Process WS-Security Header in the security settings. This change makes the proxy service an active security intermediary. If this flag is not set, authentication will fail.

Note: Sometimes the "Process WS-Security Header" settings do not appear. In our case we noticed that some non-ASCII characters in WSDL and XSD files (e.g. in the documentation elements) were causing this behaviour. Removing these characters from the WSDL and XSD files resolved this issue.


osb-silverlight-oswm-fig05
Figure 5

The applied policy does not offer the highest degree of security since it uses a cleartext name/password combination. There are alternative policies that use password hashing or authentication tokens. We could also apply message-level signing and encryption. However, for this demo case the offered level of security is sufficient and since interoperability is the main concern we chose this policy. Furthermore, no credentials will be sent over the line in cleartext since SSL is applied on transport-level.

The following snippet provides an example of a SOAP message containing a username/password combination as a WS-Security Username Token.


<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <Security s:mustUnderstand="1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd">
      <UsernameToken u:Id="7fba817f-4406-4a23-a65e-98e1df2b3e0d">
        <Username>weblogic</Username>
        <Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0#PasswordText">weblogic1</Password>
      </UsernameToken>
    </Security>
  </s:Header>
  <s:Body>
    <GreetingRequestMessage xmlns="http://www.example.org/HelloWorld/">
      <in xmlns="">Hello World !</in>
    </GreetingRequestMessage>
  </s:Body>
</s:Envelope>

Authentication Provider

Oracle WebLogic Server uses the default file-based authenticator for authentication and authorization. We can configure Oracle WebLogic Server to delegate authentication to an existing Oracle Internet Directory (OID) by configuring it as the primary authentication provider. This way the username/password combination from the WS-Security header in the request messages is verified against the LDAP-compliant OID.


osb-silverlight-oswm-fig06
Figure 6

  1. Login to the Oracle WebLogic Server console, navigate to "Security Realms" ? "Providers", and select "New" to configure a new authenticator.
  2. Select OracleInternetDirectoryAuthenticator as Type and enter a name for the new authenticator; e.g. OIDAuthenticator.
  3. Enter the required configuration to complete the wizard. The Securing Oracle WebLogic Server guide details the steps to configure OID as primary authentication provider.

That completes the necessary steps on the service-side (SSL and WSS). We can now test the secured service before we dive into the service consumer side.

Test Secured Services with soapUI

Testing the secured Web Service using soapUI is not very different than testing non-secured Web Services.

  1. Open soapUI, create a new project, and import the WSDL as you would with any Web Service. Note that we enter the HTTPS location of the WSDL instead of the HTTP location. You can find the WSDL endpoint by postfixing the OSB Proxy Service location to the URL of the OSB Managed Server; for example: https://localhost:8012/HelloWorldService/SSL?wsdl.

    Note that we use 8012 (SSL port) instead of 8011. Also note that you can configure the endpoint location in the Proxy Service settings of the Service Bus Console.
  2. Edit the soapUI project by double-clicking it in the Navigator, then navigate to Security Configurations.
  3. Add an Outgoing WS-Security Configuration by selecting the "+" icon.
  4. Enter a name for the security configuration and enter a valid username/password combination that will be used as default value. For testing purposes we can use the WebLogic account. In real life, we would probably use a new system account or dynamically populate the WS-Security Username Token with a user account. Set Password Type to PasswordText.
  5. Expand the test project in soapUI and notice that soapUI generated a Request 1 message we can use for testing.
  6. In the Aut tab in the bottom select the newly created Outgoing WSS configuration to add a WSS header. You can override the default values for the Username and Password attributes if you like.
  7. Select the green play icon to fire the test request message. Notice the WS-Security header in the request message that contains the Username Token. There should be a valid response message returned from the OSB Proxy Service.
  8. Select the SSL Info tab of the response message to inspect the SSL certificate information for the response.

osb-silverlight-oswm-fig07
Figure 7

  1. Change the request message to provide a faulty password and replay the test. You should now receive a security error from the OSB.

Let's continue with the client-side configuration now that we have tested the secured service.

Add Security Configuration to a Silverlight Client

The following sections describe how to create a Silverlight application that consumes the secured Web Service exposed by Oracle Service Bus. It shows how to add WS-Security headers to the Silverlight application and enable SSL. These steps also apply to "normal" .NET Windows Communication Foundation (WCF) applications.

Introduction to Silverlight

Microsoft Silverlight is a platform primarily used for creating Web-based applications. Silverlight requires a browser plugin comparable to Adobe Flash or Java Applets, rather than HTML 5 or server-based frameworks such as ASP.NET, JSP, and JSF that render HTML and CSS. Microsoft Silverlight can be a good choice for creating (Intranet) business applications for companies already running on Microsoft platforms.

Silverlight is based on the .NET framework. The Silverlight framework inherits a lot of the familiar classes and namespaces from its big brother. Windows Communication Foundation is the de facto standard for inter process communication in the .NET platform. Subsequently Silverlight uses a "WCF-light" for accessing Web services.

Gaining Access to a Cross-Domain Web Service from Silverlight

In a Silverlight solution, the web server does not communicate with backend Web Services. The Silverlight application runs in a browser that directly invokes the services as opposed to "classic" ASP, JSP, or JSF web applications. This means that Web Service requests can originate from a wide variety of client machines. rather than just one or two servers. In such architectures standard access control-based security (e.g. based on IP-number) is less valid since there are no central web servers that act as a fixed client to the OSB services.

Note that invocations of Web Services that do not run in the same domain or site of origin (sub domain, protocol, and port) as the Silverlight application will not be allowed by default due to security risks, such as cross-site scripting or cross-domain forgery. This can be the case when the Silverlight application runs in a different domain than the Oracle Service Bus, or when a Silverlight application is accessed though HTTP while Web Service calls are executed through HTTPS. Because of these security considerations we need to configure the environment to allow communication between the Silverlight application and the Web Service.

Note that in such cases it is strongly recommended to first analyze the involved security risks and considerations and take appropriate measurements before enabling cross-domain access. There are numerous resources available that provide information on security needs and measurements such as the Security Guides available on Oracle Technology Network.

As is the case for Adobe Flash, Microsoft Silverlight is able to process a clientaccesspolicy.xml or crossdomain.xml configuration file on the root of the server hosting the Web Services before allowing communication to the actual Web Service. Such a configuration file regulates access to the Web Services. Since the Oracle Service Bus runs on top of an Oracle WebLogic Server we will create a small WebLogic Web Application whose only task is to host a clientaccesspolicy.xml file. More background information on the ins and outs of cross-domain access can be found in Networking and Web Services in Silverlight, available in the Microsoft MSDN Library.

  1. Use Oracle Enterprise Pack for Eclipse to create a new Dynamic Web Project.
osb-silverlight-oswm-fig08
Figure 8

  1. Add the following clientaccesspolicy.xml file to the project to allow all inbound HTTP and HTTPS requests:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="SOAPAction">
        <domain uri="http://*" />
        <domain uri="https://*" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Please note that this policy file allows access from everywhere. In a real-life environment it is recommended to modify this policy accordingly (make it stricter).

After adding the file, the project in Eclipse should resemble Figure 9.


osb-silverlight-oswm-fig09
Figure 9

  1. Add a weblogic.xml deployment descriptor to the project that defines "/" (root) as context root since our clientaccesspolicy.xml file needs to live in the root.

osb-silverlight-oswm-fig10
Figure 10

  1. Export the project to a WAR file and deploy it to the WebLogic Managed Server.

osb-silverlight-oswm-fig11
Figure 11

  1. Test the deployment by accessing the clientaccesspolicy.xml file from a browser.

osb-silverlight-oswm-fig12
Figure 12

SSL Pitfalls

Remember that the OWSM policy we applied sends the WSS username/password combination in cleartext over the line. When using "PasswordText" Silverlight enforces the use of HTTPS instead of HTTP [6]. Sending cleartext passwords over HTTP defeats the purpose of adding these WSS headers to enforce security.

The next step is to import the certificate used by the server (Oracle WebLogic Server in this case) in the browser in which the Silverlight application runs. The certificate can be obtained from the WebLogic keystore using the keytool utility (part of JDK). See Securing Oracle WebLogic Server for more information.


osb-silverlight-oswm-fig13
Figure 13

Note that whenever an invalid certificate is used the browser will complain about a certificate trust issue—you will see the famous cross domain error in Silverlight when attempting to invoke the Web Service.

Implementing WS Security in Silverlight

Now it's time to create our Silverlight application using Visual Studio.

  • Create a new Silverlight project by selecting New Project from the File menu.
  • Select Silverlight in the Installed Templates pane, and complete the wizard to create the project.
  • Continue by right-clicking the newly generated project in the Solution Explorer, and select Add Service Reference to generate a Web Service proxy for the OSB service.
  • Enter the Web Service endpoint in the Address box and enter the other required settings to generate the proxy classes.

osb-silverlight-oswm-fig14
Figure 14

See How to: Create a New Silverlight Project and How to: Add, Update, or Remove a Service Reference, both from the Microsoft MSDN Library, for more detailed steps on creating a Silverlight project and creating a Web Service client.

Next we need to modify the generated Web Service bindings so the WSS message credentials are added to outbound SOAP calls and the Web Service is invoked over HTTPS. As stated earlier, Silverlight uses a subset of WFC for Web Service interactions. WCF supports the WS-Security Username Token standard [6].

We can achieve this configuration by editing the Web Service binding configuration in Visual Studio and add the following snippet:

<customBinding>
  <binding name="BasicWsSecurity">
    <security authenticationMode="UserNameOverTransport" includeTimestamp="false"/>
      <textMessageEncoding messageVersion="Soap11"/>
      <httpsTransport/>
  </binding>
</customBinding>

Now we need to set the username and password using the ClientCredentials property is used to populate the WS-Security header. This needs to be done once for every Web Service proxy:

HelloWorldClient client = new HelloWorldClient("HelloWorldSOAP_BasicWsSecurity");
client.ClientCredentials.UserName.UserName = "weblogic";
client.ClientCredentials.UserName.Password = "weblogic1";

Now that everything is setup we can run our Silverlight application and invoke the secured Web Service that is exposed by the OSB.


osb-silverlight-oswm-fig15
Figure 15

The Silverlight application shows the response message from the secured Web Service!

Summary

The added-value of interoperable standards such as WS-Security is most obvious when integrating heterogeneous platforms such as Oracle and Microsoft toolstacks. Oracle Web Services Manager (OWSM) is Oracle's primary tool to secure services and business processes by applying and enforcing standards such as SSL, WS-Security, and SAML. This is done in a declarative fashion that requires no coding and in which policies (or agents) are applied at runtime to provide the necessary security. OWSM provides dozens of predefined policies that can be readily applied to Web Services exposed by Oracle SOA Suite, OSB, and Oracle WebLogic Server (JAX-WS Web Services).

This article shows how to apply OWSM policies to a Web Service exposed by Oracle Service Bus and how to consume this Web Services from a Web Application built in Microsoft Silverlight. Silverlight is closely related to the Windows Communication Foundation (WCF) that also supports WS-Security.

Applying security measurements isn't the most trivial task. Error messages related to security can be shielded to prevent sensitive information (such as platform versions, stacktraces, required security configurations, and so) from being exposed to the outside world and payloads can be encrypted. This can make debugging in a secured environment somewhat more difficult.

Luckily there several helpful tools are available that assist in implementing and testing security. These include:

  • Fiddler – for investigating which data (requests and responses including security headers) are sent over the network.
  • soapUI – for testing and mocking Web Services including.
  • Oracle Web Services Manager – which provides a logging policy for logging inbound and outbound messages.

Standards usually leave some room for interpretation, and vendors rarely implement standards completely to the letter. There can be some smoke when the rubber hits the road in the integration of completely different technologies, such as Oracle and Microsoft platforms. See the Interoperability Guide for Oracle Web Services Manager to minimize the smoke.

Sources

  1. Security and Administrator's Guide for Web Services, Oracle Technology Network
  2. Interoperability Guide for Oracle Web Services Manager, Oracle Technology Network
  3. Securing Oracle WebLogic Server, Oracle Technology Network
  4. Silverlight homepage
  5. Networking and Web Services in Silverlight, Microsoft MSDN Library
  6. How to: Use Message Credentials to Secure a Service for Silverlight Applications, Microsoft MSDN Library
  7. Security Guides, Oracle Technology Network
  8. How to: Create a New Silverlight Project, Microsoft MSDN Library
  9. How to: Add, Update, or Remove a Service Reference, Microsoft MSDN Library

About the Authors

Ronald van Luttikhuizen is Managing Partner and Architect with Vennster and an Oracle ACE Director. LinkedIn  

Jens Peters is a Technical Architect with One Fox, a Microsoft Certified Gold Partner. LinkedIn