WS-Security Authentication

This article will cover Web services authentication using WS-Security, and the security mechanisms used in Oracle AS release 2 (10.1.3) to provide these capabilities.

Introduction

When a company begins to implement a service-oriented architecture, or adopt Web services for the first time, one of the first questions that come to mind is how users will be authenticated against Web services. Is Web services authentication similar to the authentication process for Web based applications?

Before we get to the answers, let's look at Web services and how they work. This article will first address how Web services work, and then proceed to Web services authentication.

Web Services

Web services are essentially decoupled applications. In the simplest use case, a Web service client calls a Web service. For example, consider a banking Web service, which returns an account balance based on account identification. An application would call a Web service client, which in turn invokes the bank Web service.

Both Web services and Web applications can require authentication, and each typically authenticate against a common user store. Web-based application users and Web service clients are authenticated by different means. For example, a portal user would be prompted for a username and password at the portal login page.

We'll look at how a Web service client authenticates against a Web service in the next section.

WS-Security

The OASIS WS-Security specification is the open standard for Web services security. Its goal is to let applications secure SOAP message exchanges by providing encryption, integrity, and authentication support. Let's look at how it provides authentication support for SOAP messaging.

WS-Security offers a general-purpose mechanism for associating security tokens with message content. The specification defines three approved token types:

• UsernameToken Profile
• X.509 Certificate Token Profile
• SAML (Security Assertion Markup Language) Token Profile

Each of these profiles defines how to use its token type within the WS-Security specification. For example, the UsernameToken Profile describes how a Web service client can supply a UsernameToken as a way to identify the requestor by a username and optionally by supplying a password. The following XML snippet shows a sample WS-Security UsernameToken:

<wsse:UsernameToken wsu:Id="Example">
  <wsse:Username> ... </wsse:Username> 
  <wsse:Password Type="..."> ... </wsse:Password> 
  <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> 
  <wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>

To authenticate using WS-Security, you'd need to add a SOAP header to the SOAP envelope. This header would contain the WS-Security information, as follows:

<?xml version="1.0" encoding="utf-8"?>
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> 
   <S11:Header>
     <wsse:Security xmlns:wsse="...">
        <wsse:UsernameToken wsu:Id="Example">
          <wsse:Username> ... </wsse:Username> 
          <wsse:Password Type="..."> ... </wsse:Password> 
          <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> 
          <wsu:Created> ... </wsu:Created>
        </wsse:UsernameToken>
      </wsse:Security> 
  </S11:Header>
 <S11:Body wsu:Id="MsgBody">
    <tru:getBalance xmlns:tru="http://samplebank.com/ws"> 
      65712356
    </tru:getBalance>
  </S11:Body>
</S11:Envelope>

In general, a Web Service client doesn’t actively manipulate the SOAP envelope to add authentication details. The client has a security interceptor that intercepts the outgoing SOAP envelope, and then adds the WS-Security authentication details. A security interceptor could be a XML firewall, a JAX-RPC Handler, or a similar agent.

The SOAP Web service acts in a similar fashion. A security interceptor intercepts the incoming SOAP envelope before it arrives at the Web service, processes the WS-Security element, and validates the username and password.

Oracle 10.1.3 provides pre-built interceptors (JAX-RPC Handlers) to provide Username, X.509, and SAML token capabilities. These interceptors can be chosen declaratively using JDeveloper, or they can be configured in the Application Server Control. The idea behind the security interceptors is to make security transparent to developers.

The following diagram illustrates a Web service client invoking a Web Service. A security interceptor catches the outbound SOAP envelope and adds authentication details to the SOAP header. The interceptor may get the details from the Portal from a callback handler, or from JAX-RPC properties. The Web service also has a security interceptor that catches the inbound SOAP envelope, and verifies the username-password pair in the UsernameToken. If they are valid, then allow access to the Web service.

In the case of a Username token, Oracle has integrated its XML and OID JAZN providers with the Security Interceptors to validate users.

If a X.509 Certificate Token were used instead of the Username Token, then the validation process would be similar. The security interceptor sitting in front of the Web service would validate the requestor’s digital certificate. The certificate’s signature would be verified, and if the certificate were found to be valid, then the user would be allowed access to the Web service.

Web Services and Single Sign-On

There is a WS-Security authentication mechanism that we haven’t covered: the SAML (Security Assertion Markup Language) Token Profile. SAML is an XML-based security framework for exchanging authentication and authorization information. It's the enabling glue for distributed and single sign-on architectures.

In our banking example, SAML could be used to provide single sign-on capabilities between the bank's Web applications, and its Web services.

Once again, let's return to our portal application scenario, using a SAML Token for authentication means. In this case, a user has logged into the Portal and is trying to get his bank balance. The Portal calls the Web service client to get this data from the Web service, as in Figure 2:

Let's look at what happens when user logs in to the portal:

1. When the user logs into the portal, their credentials are checked. If they’re valid, the user is allowed to access the portal.
   
   
2. The user tries to access his bank account balance. The portal calls the Web service client on the user’s behalf.
   
   
3. A Security Interceptor intercepts the outgoing message to add a WS-Security SAML authentication token (SAML assertion) to the message header. This token asserts that the user has already authenticated, and further logins are not required.
   
   
4. The SOAP message is then sent to the service.
   
   
5. The receiving Security Interceptor verifies the SAML token. If it's valid, the interceptor allows access to the Web service.

The idea behind this process is that once a user has been authenticated, he shouldn't have to authenticate again. The beauty of SAML is it can combine the power of Web application and Web service based single sign-on in an interoperable, standard way.

Conclusion

The trend today is to make security as declarative as possible. Companies need to be able to change their policies as security audits, or choices dictate. Oracle provides these capabilities by removing the complexity of implementing security, and easing the management of change.