2 Understanding Web Services Security Concepts

This chapter introduces the Web services security concepts. It is divided into the following sections:

For an introduction to general Web service concepts, see "What are Web Services" in Introducing Web Services.

Securing Web Services

Because of its nature (loosely coupled connections) and its use of open access (mainly HTTP), SOA implemented by Web services adds a new set of requirements to the security landscape. Web services security includes several aspects:

  • Authentication—Verifying that the user is who she claims to be. A user's identity is verified based on the credentials presented by that user, such as:

    1. Something one has, for example, credentials issued by a trusted authority such as a passport (real world) or a smart card (IT world).

    2. Something one knows, for example, a shared secret such as a password.

    3. Something one is, for example, biometric information.

    Using a combination of several types of credentials is referred to as "strong" authentication, for example using an ATM card (something one has) with a PIN or password (something one knows).

  • Authorization (or Access Control)—Granting access to specific resources based on an authenticated user's entitlements. Entitlements are defined by one or several attributes. An attribute is the property or characteristic of a user, for example, if "Marc" is the user, "conference speaker" is the attribute.

  • Confidentiality, privacy—Keeping information secret. Accesses a message, for example a Web service request or an email, as well as the identity of the sending and receiving parties in a confidential manner. Confidentiality and privacy can be achieved by encrypting the content of a message and obfuscating the sending and receiving parties' identities.

  • Integrity, non repudiation—Making sure that a message remains unaltered during transit by having the sender digitally sign the message. A digital signature is used to validate the signature and provides non-repudiation. The timestamp in the signature prevents anyone from replaying this message after the expiration.

Web services security requirements also involve credential mediation (exchanging security tokens in a trusted environment), and service capabilities and constraints (defining what a Web service can do, under what circumstances).

In many cases, Web services security tools such as Oracle WSM rely on Public Key Infrastructure (PKI) environments. A PKI uses cryptographic keys (mathematical functions used to encrypt or decrypt data). Keys can be private or public. In an asymmetric cipher model, the receiving party's public key is used to encrypt plaintext, and the receiving party's matching private key is used to decrypt the ciphertext. Also, a private key is used to create a digital signature by signing the message, and the public key is used for verifying the signature. Public-key certificates (or certificates, for short) are used to guarantee the integrity of public keys.

Web services security requirements are supported by industry standards both at the transport level (Secure Socket Layer) and at the application level relying on XML frameworks.

For more information about the specifications, standards, and security tokens supported by Web services, see Appendix A, "Web Service Security Standards."


Oracle has been instrumental in contributing to emerging standards, in particular the specifications hosted by the OASIS Web Services Secure Exchange technical committee.

Transport-level Security

Secure Socket Layer (SSL), otherwise known as Transport Layer Security (TLS), the Internet Engineering Task Force (IETF) officially standardized version of SSL, is the most widely used transport-level data-communication protocol providing:

  • Authentication (the communication is established between two trusted parties).

  • Confidentiality (the data exchanged is encrypted).

  • Message integrity (the data is checked for possible corruption).

  • Secure key exchange between client and server.

SSL provides a secure communication channel, however, when the data is not "in transit," the data is not protected. This makes the environment vulnerable to attacks in multi-step transactions. (SSL provides point-to-point security, as opposed to end-to-end security.)

Application-level Security

Application-level security complements transport-level security. Application-level security is based on XML frameworks defining confidentiality, integrity, authenticity; message structure; trust management and federation.

Data confidentiality is implemented by XML Encryption. XML Encryption defines how digital content is encrypted and decrypted, how the encryption key information is passed to a recipient, and how encrypted data is identified to facilitate decryption.

Data integrity and authenticity are implemented by XML Signature. XML Signature binds the sender's identity (or "signing entity") to an XML document. Signing and signature verification can be done using asymmetric or symmetric keys.

Signature ensures non-repudiation of the signing entity and proves that messages have not been altered since they were signed. Message structure and message security are implemented by SOAP and its security extension, WS-Security. WS-Security defines how to attach XML Signature and XML Encryption headers to SOAP messages. In addition, WS-Security provides profiles for 5 security tokens: Username (with password digest), X.509 certificate, Kerberos ticket, Security Assertion Markup Language (SAML) assertion, and REL (rights markup) document.

The SOAP envelope body includes the business payload, for example a purchase order, a financial document, or simply a call to another Web service. SAML is one of the most interesting security tokens because it supports both authentication and authorization. SAML is an open framework for sharing security information on the Internet through XML documents. SAML includes 3 parts:

  • SAML Assertion—How you define authentication and authorization information.

  • SAML Protocol—How you ask (SAML Request) and get (SAML Response) the assertions you need.

  • SAML Bindings and Profiles—How SAML assertions ride "on" (Bindings) and "in" (Profiles) industry-standard transport and messaging frameworks.

The full SAML specification is used in browser-based federation cases. However, web services security systems such as Oracle WSM only use SAML assertions. The protocol and bindings are taken care of by WS-Security and the transport protocol, for example HTTP.

SAML assertions and references to assertion identifiers are contained in the WS-Security Header element, which in turn is included in the SOAP Envelope Header element (described in the WS-Security SAML Token Profile). The SAML security token is particularly relevant in situations where identity propagation is essential.

Web Service Security Requirements

The following summarize the Web service security requirements:

  1. The use of transport security to protect the communication channel between the Web service consumer and Web service provider.

  2. Message-level security to ensure confidentiality by digitally encrypting message parts; integrity using digital signatures; and authentication by requiring username, X.509, or SAML tokens.

Oracle Web Services Manager (WSM) is designed to define and implement Web services security in heterogeneous environments, including authentication, authorization, message encryption and decryption, signature generation and validation, and identity propagation across multiple Web services used to complete a single transaction.

How Oracle Fusion Middleware Secures Web Services and Clients

Figure 2-1 shows an Oracle Fusion Middleware application that demonstrates some common interactions between Web services and their clients. How security is managed at each step in the process is explained following the figure.

The Oracle WSM Policy Manager (labeled as OWSM in Figure 2-1) is the security linchpin for Oracle Fusion Middleware Web services and SOA applications. For more information about how the Oracle WSM Policy Manager manages the policy framework, see Chapter 3, "Understanding Oracle WSM Policy Framework."


To ensure the security of your Web services, the Policy Manager must be running before starting any Web services. If the Policy Manager is deployed on a separate server (other than the servers running Web services), make sure that it is up and running before starting the other servers.

Figure 2-1 Example of Oracle Fusion Middleware Application

Description of Figure 2-1 follows
Description of "Figure 2-1 Example of Oracle Fusion Middleware Application"

As shown in the previous figure, there are two types of policies that can be attached to Web services: Oracle WSM policies and WebLogic Server polices. For more information, see Table 1-1, "Types of Web Service Policies".

The following describes in more detail the Web service and client interactions called out in the previous figure, and how security is managed at each step in the process. As noted in the figure, security is managed using both Oracle WSM policies and WebLogic Web service policies.

  1. At design time, you attach Oracle WSM and WebLogic Web service policies to applications programmatically using your favorite IDE, such as Oracle JDeveloper.

    Alternatively, at deployment time you attach policies to SOA composites, ADF, and WebCenter applications using the Oracle Enterprise Manager Fusion Middleware Control, and to WebLogic Web services (Java EE) using the WebLogic Server Administration Console (not shown in the figure).

    Note: Policies that are attached to WebLogic Web services at design time cannot be detached at deployment time. You can only attach new policies.

  2. A user logs in to the ADF Web application.

    The user may be internal or external to Company A.

  3. Using a Web service data control, the ADF Web application accesses a service, such as a WebLogic Web service, a SOA composite application, or an ADF Business Component.

    At the Web service client side, Oracle WSM intercepts the SOAP message request to the service, injects the relevant tokens, and signs and encrypts the message, as required by the attached policies.

    At the Web service side, Oracle WSM intercepts the SOAP message request to the service, extracts the tokens, and verifies the client's credentials against an identity management infrastructure (for example, a file, an LDAP-compliant directory, or Oracle Access Manager), as required by the attached policies.

  4. Interactions with the SOA service components (shown in the figure) include:

    1. The SOA service component accesses an ADF Business Component to query or update tables in a database.

    2. A WebCenter client access the SOA service component to process a customer request.

    3. The SOA service component accesses the Web service internal to Company A to accomplish a specific task.

    4. The SOA service component accesses a Web service via an external provider (Company B) to accomplish a specific task. As long as you know the URL that identifies the WSDL document, you can access the Web service.

    Again, at the Web service client side, Oracle WSM intercepts the SOAP message request to the service, injects the relevant tokens, and signs and encrypts the message, as required by the attached policies.

    At the Web service side, Oracle WSM intercepts the SOAP message request to the service, extracts the tokens, and verifies the client's credentials against an identity management infrastructure (for example, a file, an LDAP-compliant directory, or Oracle Access Manager), as required by the attached policies.

  5. A client accesses a WebLogic Java EE Web service.

    In this case, components in a larger composite application interact with the WebLogic Web service. An Oracle WSM policy is used to secure the WebLogic JAX-WS Web service client. A WebLogic Web service policy is used to secure the WebLogic JAX-RPC service client.