5 Secure Web Service Usage Scenarios

This chapter describes common scenarios for using Web service Security. It begins with the simplest use case, then proceeds through increasingly more complex use cases. The first section of the chapter discusses use cases with no security implications; these are then modified to add security features. This chapter is divided into the following sections:

• Non-Secured Web Services

• HTTP-Based Security

• WS-Security

• XML Signature

• XML Encryption

• Gateways

• Identity Management

• Interoperability

Non-Secured Web Services

This section contains simple use cases that do not use WS-Security. These use cases serve as a basis to demonstrate adding security features.

• Basic Web Service

• Complex Business Process

• Intermediary

• Federated

For information on how to implement non-secured Web services see the Oracle Application Server Web Services Developer's Guide.

Basic Web Service

Figure 5-1 illustrates a basic Web service use case, where a Web service client invokes a Web service:

Figure 5-1 Basic Web Service Use Case

Description of "Figure 5-1 Basic Web Service Use Case"

This Web service offers real-time stock quotes to its clients. The Web service client supplies a stock ticker symbol, for example "ORCL", and expects the current value of the stock as the response.

Complex Business Process

Figure 5-2 illustrates a complex workflow, a bank's Web service that allows users to apply for an auto loan.

Figure 5-2 Complex Business Process

Description of "Figure 5-2 Complex Business Process"

The Bank Web service receives an applicant's application from a Web service client, then invokes a Web service to make an inquiry to a credit bureau. The Bank Web service contains a Web service client that invokes the credit bureau Web service. The bureau sends a response back to the Bank Web service; this response might be an approval or no-approval string and the credit score of the applicant.

Intermediary

Figure 5-3 illustrates an intermediary that separates a Web service client and a Web service. This intermediary could be an external notary service, an XML firewall, a BPEL process manager, or a quality of service (QOS) agent.

Figure 5-3 Intermediary Use Case

Description of "Figure 5-3 Intermediary Use Case"

A typical intermediary does not modify the contents of the SOAP body, but adds or modifies SOAP headers. For example, an XML firewall might validate content, authenticate and authorize users, but would not process the SOAP body, because the intermediary is not the Web service's final destination.

Federated

The federated use case is similar to the basic use case, except that it spans security boundaries. Figure 5-4 shows a company that allows its customers to submit purchase orders through a Web service; note that the company exposing the Web service does not own or control the Web service client.

Figure 5-4 Federated Use Case

Description of "Figure 5-4 Federated Use Case"

HTTP-Based Security

The traditional method of securing data, such as SOAP messages, transmitted over HTTP is to use the Secure Sockets Layer and HTTP authentication.

• Secure Sockets Layer

• HTTP Basic Authentication and Digest Authentication

Secure Sockets Layer

The Secure Sockets Layer (SSL) prevents intermediate applications from reading a message transmitted between a client and a server. SSL uses public-key encryption to exchange a session key between the client and server; this session key is used to encrypt the HTTP request and response traffic. SSL is the most commonly used HTTP-based security solution. Figure 5-5 illustrates the flow of data when using SSL encryption.

Figure 5-5 SSL Encryption In a Web Service

Description of "Figure 5-5 SSL Encryption In a Web Service"

For the steps to configure SSL, see the Oracle Containers for J2EE Security Guide.

Note: Oracle Application Server Web Services also supports TLS encryption; for details, see the Oracle Database Advanced Security Administrator's Guide.

HTTP Basic Authentication and Digest Authentication

Business requirements often dictate that access to Web services be restricted to authenticated users. The following sections describe the two most common approaches.

• Basic Authentication

• Digest Authentication

For information on how to implement basic and digest authentication, see the Oracle Containers for J2EE Security Guide.

Basic Authentication

When using basic authentication, the Web service client authenticates itself to the service by sending a base-64 encoded user name and password in an HTTP authorization header. Basic authentication has a security weakness: it sends credentials using base-64 encoding, which is trivial to decode. Sending credentials in a base-64 encoding is nearly as insecure as sending them in the clear. Figure 5-6 illustrates the flow of data when using basic authentication.

Figure 5-6 HTTP Basic Authentication in a Web Service

Description of "Figure 5-6 HTTP Basic Authentication in a Web Service"

When a Web service validates an authentication request, it must do so against a credential store. In OracleAS Web Services applications, authentication requests are validated through the LDAP security provider. For example, your Web service could be configured to use an LDAP provider.

Figure 5-7 Basic Authentication With LDAP

Description of "Figure 5-7 Basic Authentication With LDAP"

Digest Authentication

Digest authentication uses the same HTTP headers as basic authentication, but it transmits a digest for the password. Although digest authentication is much more secure than basic authentication, it is not interoperable in all security environments, so is rarely used. Also, digest authentication uses weak algorithms such as MD5. Encrypting transmissions using SSL is the preferred method to prevent credential snooping.

Figure 5-8 Digest Authentication

Description of "Figure 5-8 Digest Authentication"

WS-Security

Oracle provides pre-built JAX-RPC handlers called interceptors to provide WS-Security message-level security. For outbound messages, these interceptors add the necessary WS-Security headers to support WS-Security authentication, XML encryption, and XML digital signature operations; for inbound messages, the interceptors process the corresponding header information.

Figure 5-9 Interceptor Framework

Description of "Figure 5-9 Interceptor Framework"

Note: An application can use SSL alone, WS-Security alone, or both together.

Web Services Security Authentication

WS-Security authentication is more flexible than either basic or digest authentication. WS-Security provides three different authentication profiles to authenticate against a Web service:

• Username Token Profile

• X.509 Token Profile

• SAML Token Profile

Each of these profiles defines how to use its token type within the WS-Security specification. Oracle provides a pre-built interceptor for all the WS-Security Token profiles.

Username Token Profile

The Username Token Profile is similar to HTTP basic and digest authentication. Applications can construct a username token with three different credential types:

• username without password

• username with password

• username with encrypted password

The username token interceptor adds the token to the SOAP envelope.

If hosted on OracleAS Web Services, the receiving Web service also has a username token interceptor. The interceptor processes the username token and validates the credentials contained within it against the Web service's configured security provider, such as the Oracle Internet Directory LDAP-based provider.

Figure 5-10 Username Token Use Case

Description of "Figure 5-10 Username Token Use Case"

The username token use case is a common use case for OracleAS Portal and other Web-based applications; its advantage is that all credential checks are made against a central user repository.

For information on how to configure the username token, see "Using a Username Token".

X.509 Token Profile

The X.509 Profile uses an X.509 certificate to authenticate against the receiving Web service. Oracle provides a pre-built interceptor that adds WS-Security X.509 authentication to outbound messages. A certificate token is added to the WS-Security header in the outgoing SOAP envelope. The certificate is read from a credential store such as an Oracle Wallet or a Java keystore.

Figure 5-11 X.509 Token Use Case

Description of "Figure 5-11 X.509 Token Use Case"

Under OracleAS Web Services, the interceptor on the receiving Web service validates the X.509 certificate's signature and then checks to see if the user exists in the directory. The distinguished name in the certificate must have a match in the directory. If the receiving Web service is an external J2EE container or .NET Web service, it provides its own means of validating the WS-Security X.509 certificate.

For information on how to configure the X.509 token, see "Using an X.509 Token".

SAML Token Profile

SAML tokens, unlike Username and X.509, assert that the SAML user or subject has already been authenticated. SAML security tokens are composed of assertions: one or more statements about a user. SAML assertions are attached to SOAP messages using WS-Security by placing assertion elements inside the header. Oracle supports two SAML use cases: sender vouches and holder of key.

For information on how to configure the SAML token for these use cases, see "Using a SAML Token".

Sender Vouches

In the sender vouches use case, the sender vouches for the verification of the assertion's subject. The sender's private key is used to sign both the assertion and the message body. If the sender gets the assertion from a SAML authority, then the SAML authority could also sign the message. In this scenario double signing of the assertion may occur.

Figure 5-12 SAML Assertion Use Case

Description of "Figure 5-12 SAML Assertion Use Case"

Holder of Key

In the holder of key use case, the sender submits a request for an assertion to the SAML authority. The issuer then returns a signed assertion with user's public key embedded in it. The sender then signs the message body with their private key.

Figure 5-13 SAML Authority Assertion Use Case

Description of "Figure 5-13 SAML Authority Assertion Use Case"

XML Signature

XML signatures ensure message integrity for SOAP messages. When you use XML signatures, outbound message bodies are digitally signed with the sender's private key. The receiver uses the sender's public key to validate the signature.

Figure 5-14 Digital Signature Use Case

Description of "Figure 5-14 Digital Signature Use Case"

Oracle also supports protecting the integrity of the message response. There are many scenarios for using XML signatures to sign message bodies, message headers, or parts of either. For example, an application could sign the whole message body to officially identify the sender. Another application could sign several of the elements of the body, each element from a different origin and identified by a signature from a different signer. The signature can also be used to validate content integrity, detecting tampering during transit or storage.

For information on how to configure XML signature in a Web service, see "Configuring XML Signature".

XML Encryption

XML encryption allows the encryption of an XML element, which could be the SOAP body, the SOAP header, or any XML element within these structures. The interceptor substitutes an encrypted element for the original XML data; the receiver is responsible for decrypting the element.

Figure 5-15 XML Encryption Use Case

Description of "Figure 5-15 XML Encryption Use Case"

XML encryption is used for targeted encryption. An application could encrypt an entire message body or encrypt only sub-elements within a message body. XML encryption does not replace SSL; the two can be used together or separately. For example, a SOAP payload may contain a credit check that uses XML encryption only on the elements that contain the credit card account numbers. It may be that this information isn't encrypted until reaching a final destination in a multi-step process. Therefore the entire message is sent over SSL to protect it while in transit.

To support encryption, the interceptor must be able to access a Java keystore or an Oracle Wallet. For XML encryption, the Web service client uses the Web service's public key. The Web service decrypts any XML encrypted elements sent by the client by using its private key.

For information on how to configure XML encryption in a Web service, see "Configuring XML Encryption".

Gateways

Some applications use gateways (centralized policy enforcement points) to implement message security, instead of applying security within a J2EE container. Gateways can be useful as checkpoints that all Web services must traverse before accessing external Web services. For example, there could be a gateway that separates a company's Web service clients and external Web services. This gateway would enforce WS-Security policies on all outbound Web services.

The gateway shown in Figure 5-6 ensures that all outbound messages are signed.

Figure 5-16 Gateway Use Case

Description of "Figure 5-16 Gateway Use Case"

Identity Management

Web services often authenticate and authorize against an Identity Management infrastructure. In OracleAS Web Services, the interceptors use the Identity Management security provider configuration to determine where to authenticate. For example, if the provider is the LDAP provider, then it will authenticate against an LDAP directory.

Figure 5-17 Identity Management Use Case

Description of "Figure 5-17 Identity Management Use Case"

Interoperability

Many business situations require a mixed-vendor environment, in which, for instance, Oracle web service clients interact with .NET Web services.

Figure 5-18 Interoperability Use Case

Description of "Figure 5-18 Interoperability Use Case"

There are a number of use cases for interoperability between vendors to consider with Web services. Interoperability between vendors is covered by the Basic Security Profile (BSP) specification which is available from the Web Services Interoperability (WS-I) organization (http://www.ws-i.org/).