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.
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.
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:
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).
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.
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:
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 (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:
The functionality offered by those policies includes:
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.
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.
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:
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.
The "HelloWorld" demo showing the case consists of the following steps that will be explained in the following sections:
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.
Since we need to implement transport-level security we have to make sure the Managed Server supports SSL.
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.
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.
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.
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>
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.
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.
Testing the secured Web Service using soapUI is not very different than testing non-secured Web Services.
Let's continue with the client-side configuration now that we have tested the secured service.
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.
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.
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.
<?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.
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 . 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.
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.
Now it's time to create our Silverlight application using Visual Studio.
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 .
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.
The Silverlight application shows the response message from the secured Web Service!
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:
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.
Jens Peters is a Technical Architect with One Fox, a Microsoft Certified Gold Partner.