Skip Headers

Oracle® Application Server Web Services Security Guide 10g Release 3 (10.1.3) B15979-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 1 Introduction

This chapter introduces essential Web service security concepts, standards, and specifications. It is divided into the following sections:

- Web Service Security Concepts

- Web Services Security Support in OracleAS Web Services

- Tool Support for Web Service Security

Historically, the majority of Web services have been based on the same enabling technology that underlies the Web, namely HTTP. As a result, common technologies that secure Web applications, such as basic authentication and SSL, work equally well with Web services. These security technologies have been effective for years for all sorts of online business transactions, and they work equally well for Web services.

SSL, however, does have limitations. SSL for Web services is an all-or-nothing proposition: it often secures the entire wire protocol rather than just the SOAP message sent over the protocol. It doesn't let developers apply different levels of security to different parts of a document. Because of its point-to-point structure, SSL doesn't support chained services or workflow applications where user credentials can be passed through each stop in a transaction chain. This leaves the messages unsecured at each intermediary checkpoint. SSL also does not support the concept of an audit trail.

The answer to providing both message- and transport-level security lies with the OASIS standard, WS-Security, released as a full industry-recognized recommendation in April 2004. WS-Security defines a mechanism for adding transport independence and different levels of security to SOAP messages.

- WS-Security offers multiple ways to authenticate. In WS-Security, it is easy to associate different identities with service requests. These identities can be used to enforce authorization after authentication.

- WS-Security offers support for SOAP traffic involving intermediaries.

- WS-Security is transport-independent, which gives greater transport flexibility.

- WS-Security is targeted security. For example, you can sign or encrypt the whole message body, or just a single XML element of the body payload.

If there is a need to apply integrity and confidentiality at a fine-grained level instead of applying to the entire SOAP message, XML signature and encryption can be used to protect the SOAP body, header block, or portions of either. If the SOAP message needs to be protected beyond the transport session, message-level security can be used. If there is a need to use different forms of authentication, then message-level security authentication tokens can be used, such as username token, X.509 token, or SAML token.

## Web Service Security Concepts

The concepts fundamental to security are authentication, message integrity, and message confidentiality.

- Authentication — "Who is trying to access my services?" Applications need to know whom they're serving.

- Message integrity —"Was the message lost, destroyed, or modified in transit, either accidentally or deliberately?" Applications must validate messages.

- Message confidentiality—"Can anybody else read this message?" Applications may need to encrypt data between endpoints, revealing data to only applications that need to see it.

A number of Web services and security-related terms and concepts are used throughout this book. They are described in the following sections.

- SOAP

- Security Policies

- The Request Envelope

- The Response Envelope

- XML Digital Signatures

- XML Encryption

- SAML

- Message-Level Security

- Transport-Level Security

- WS-Security

- Security Tokens

### SOAP

The SOAP protocol is an XML-based standard for Web service request and response messages, which are normally transmitted over the HTTP or HTTPS (HTTP with SSL) protocols. WS-Security is an XML-based extension to the SOAP description, designed to fit within the SOAP message context. To see this, one must first understand the anatomy of a SOAP message.

In the XML schema definition for SOAP, the `<Envelope>` element is the root element of a SOAP message. A SOAP message can also have headers, a body, or a fault element. Example 1-1 illustrates the contents the SOAP `<Envelope>` element.

Example 1-1 Contents of the SOAP <Envelope> Element

    <env:Envelope>
        <env:Header>
        </env:Header>
      <env:Body>
           .
           .
           .
      </env:Body>
    <env:Envelope>

Note: This example illustrates a SOAP request envelope. There is also a response envelope, which can contain a SOAP fault element.

Although Web services developers are primarily concerned with the contents of the SOAP body, most security-related elements appear in the SOAP header. The body itself can be encrypted, in which case it contains ciphertext.

### Security Policies

A Web service security policy determines the security mechanism that is applied to a SOAP message. Security policies can be applied to the Web service on the server side and to the Web service client. Oracle Application Server Web Services Security recognizes the following types and levels of security policies.

- Inbound Policy

- Outbound Policy

- Global Level Policy

- Port-Level Policy

- Operation-Level Policy

#### Inbound Policy

An inbound policy determines the security mechanisms applied to the inbound SOAP message. The `decrypt` value and the `verify-username-token` value are two examples of inbound policies. The decrypt value represents a policy which is used for decrypting the inbound SOAP message. The `verify-username-token` value represents a policy; this indicates that the incoming SOAP request is carrying a username token which must be verified and authenticated.

To configure an inbound policy, you can use Application Server Control, JDeveloper, or create the configuration manually. The security configuration appears as subelements beneath an `<inbound>` element. The `<inbound>` element and its configuration can appear in the `oracle-webservcies.xml` file for a Web service application and `<``generated_name``>_Stub.xml` file for a Web service client. For more information about the contents of the `<inbound>` element, see "Security Elements for Inbound Messages".

#### Outbound Policy

An outbound policy determines the security mechanisms applied to the outbound SOAP message. The `<encrypt>` value and the `<username-token>` value are two examples of outbound policies. The `<encrypt>` value represents a policy, which is used for encrypting the outbound SOAP message. The `<username-token>` value represents a policy, which indicates that a username token must be included in the outgoing SOAP message.

To configure an outbound policy, you can use Application Server Control, JDeveloper, or create the configuration manually. The security configuration appears as subelements beneath an `<outbound>` element. The `<outbound>` element and its configuration can be used in the `oracle-webservcies.xml` file for a Web service application and `<``generated_name``>_Stub.xml` file for a Web service client. For more information about the contents of the `<outbound>` element, see "Security Elements for Outbound Messages".

#### Global Level Policy

A global-level security policy is a security policy that is applied to all of the Web services deployed in an OC4J instance. Global-level policies can be configured only on the server side.

You can configure the following items at the global level:

- Keystore, signature and encryption keys

- Nonce configuration

- Inbound policy

- Outbound policy

#### Port-Level Policy

In the Web service context, a port is analogous to an application. A port-level security policy is a security policy that is applied to all operations defined in that Web service. Port-level policies can be configured on the server and the client side.

You can configure the following items at the port level:

- Keystore, signature and encryption keys

- Nonce configuration

- Inbound policy

- Outbound policy

#### Operation-Level Policy

An operation-level security policy is a security policy that is applied to a particular operation of a Web service. Operation-level policies can be configured on the server and the client side.

You can configure the following items at the operation level:

- Inbound policy

- Outbound policy

### The Request Envelope

A request envelope contains the information required to process a remote call. Each request message contains a message header and a message body. The header stores processing information such as message routing, requirements information, and security information. The body of the message stores the information required to process the call; this information is also known as the payload.

The payload contains the following items:

- Name of the service called

- Location of the service

- Parameter name and data passed to the service

### The Response Envelope

SOAP response envelope format-type is identical to the request. The only difference is that the `IN` parameter is replaced by an `OUT` parameter. The application's output is included in the SOAP body.

Note: The structure of the request and response envelopes might differ based on whether the service supports the RPC-encoded and/or document-literal message format. For more information on supported message formats, see "Oracle Application Server Web Services Messages" in the Oracle Application Server Web Services Developer's Guide.

### XML Digital Signatures

The XML signature specification describes digital signature processing rules and syntax. XML signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

An XML signature contains the basic hash of the signed document, along with information that tells the recipient of the document what data was signed and which algorithms were used. An XML signature can be included inside the document to which the signature applies, or it can exist in a separate document. An XML signature can be applied to document subsets, or even to non-XML data.

XML Signature supports various types of signature, including:

- enveloped—the signature contains the data that is being signed; the signature and element being signed are embedded in the same element.

- enveloping—the signature containing the signed data is embedded in itself.

- detached—the signature corresponds to data external to the signature element.

For more information about XML Signature, see the specification at the following Web site.

`http://www.w3.org/TR/xmldsig-core`

XML Signatures and Web Services

For a Web service, XML digital signatures ensure the validity, and identity of SOAP messages sent between Web service clients and services. They are similar in concept to a handwritten signature, where only one person, the signer, can produce the signature. Signature validation is performed in two steps.

1. Compute the message digests of all SOAP message elements to be signed, then place the digests in the `<SignedInfo>` element of the message signature.

2. Compute the message digest of the `<SignedInfo>` element, then sign this digest with the signer's private key. Place the key used for signing in the `<KeyInfo>` element.

The signed SOAP message then is transmitted and verified at the Web service endpoint by the signer's public key. The following steps illustrate how verification works.

1. Recalculate the value of the `<SignedInfo>` element using the digest algorithm specified in the `<SignatureMethod>` element. Use the public key to verify that the value of the `<SignatureValue>` element is correct for the digest of the `<SignedInfo``>` element.

2. Recalculate the digests of the references contained within the `<SignedInfo>` element and compare them to the digest values expressed in each `<Reference>` element's corresponding `<DigestValue>` element.

Example 1-2 illustrates the XML representation of signed data. The body of the SOAP message is signed with the RSA-SHA1 algorithm.

Example 1-2 XML Representation of Signed Data

    <dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
                           xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <dsig:SignedInfo>
        <dsig:CanonicalizationMethod
             Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <dsig:SignatureMethod
             Algorithm="http://www.w3.org/2000/09/xmldsig#*rsa-sha1*"/>
        <dsig:Reference URI="*#body*">
          <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <dsig:DigestValue>p5vhdagV0tjJafczbLB/I4aonlg=</dsig:DigestValue>
        </dsig:Reference>

      </dsig:SignedInfo>
             <dsig:SignatureValue>QKEJpRGwwRApPFWfA1R/6K4JFwCxyH2Ur0mdzTnzmpf
                                  8DNvDVB9xdF9PVsQ68vEey8afbrL/Qwujghoq3gF22VlEBPj
                                  TDrRTZ9JgnRVbOt/M/SacHP/BZn9gSfLySpJaQIj7x
                                  MUbm5s29JiUvjQ0oR0/Skn+8f+KeQD0QEmbWX8=
      </dsig:SignatureValue>
      <dsig:KeyInfo>
        <wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/
                                      oasis-200401-wss-wssecurity-secext-1.0.xsd"
                                     xmlns:wsse="http://docs.oasis-open.org/wss/2004/
                                      01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                                      wsu:Id="_str"
                                     xmlns:wsu="http://docs.oasis-open.org/wss/2004/
                                      01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <wsse:Reference xmlns="http://docs.oasis-open.org/wss/2004/
                                       01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                                     xmlns:wsse="http://docs.oasis-open.org/wss/2004/
                                       01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                                       URI="#_bst"/>
        </wsse:SecurityTokenReference>
      </dsig:KeyInfo>
    </dsig:Signature>

### XML Encryption

The XML encryption specification describes a process for encrypting data and representing the result in XML. The data can be arbitrary; for example, it can be an XML document, an XML element, or XML element content. The result of encrypting data is an XML encryption element which contains (by using one of its children's content) or identifies (by using a URI reference) the cipher data. The standard allows selected parts of a document to be encrypted, while the document as a whole remains valid XML.

XML encryption supports different encryption types such as:

- symmetric key encryption

- public key encryption

For more information about XML Encryption, see the specification at:

`http://www.w3.org/TR/xmlenc-core`

XML Encryption and Web Services

For a Web service, XML encryption provides security for applications that require a secure exchange of data. While SSL was considered the standard way to secure data exchanges, it has limitations. For example, assume that a document visits several web services before hitting its eventual endpoint. By using XML encryption, the document can be encrypted while at rest, or in transport. It is also possible to encrypt only portions of a document, instead of the whole document.

Example 1-3 illustrates credit card data represented in XML.

Example 1-3 XML Representation of Credit Card Data

      <PaymentInfo xmlns='http://example.org/paymentv2'>
        <Name>John Smith</Name>
        <CreditCard Limit='5,000' Currency='USD'>
          <Number>4019 2445 0277 5567</Number>
          <Issuer>Example Bank</Issuer>
          <Expiration>04/02</Expiration>
        </CreditCard>
      </PaymentInfo>

Example 1-4 illustrates the same XML snippet with the credit card number, spending limit, issuing bank, and expiration date encrypted and represented by a cipher value.

Example 1-4 XML Representation of Encrypted Credit Card Data

      <PaymentInfo xmlns='http://example.org/paymentv2'>
        <Name>John Smith</Name>
        <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
         xmlns='http://www.w3.org/2001/04/xmlenc#'>
          <CipherData>
            <CipherValue>A23B45C56</CipherValue>
      </CipherData>
        </EncryptedData>
      </PaymentInfo>

### SAML

The Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, either human or computer, that have identities in some security domain. One example of a subject is a person, who is identified by his or her email address in a particular Internet DNS domain. Assertions convey information about authentication acts performed by subjects, attributes of subjects, as well as authorization decisions about whether subjects are allowed to access certain resources.

SAML provides a flexible and extensible framework for business and Web services to exchange security information, such as authentication, authorization, and attributes, about their users. For example, SAML allows one service to vouch for a user's authentication to another service. This allows useful activities, such as single sign-on to multiple services.

SAML allows one service to inform another service whether a user is allowed to access a given resource. This allows policy enforcement to be decoupled from resource services.

SAML allows attribute information about a user, such as work-site address, to be communicated between services as the user moves from one site to another.

### Message-Level Security

Oracle's Web Services Security model supports end-to-end security via message-level security. This means that in addition to the connection, the SOAP message itself is secure even when it is transferred across multiple intermediaries. The SOAP message is digitally signed and encrypted. You can apply signature and encryption at a granular level by specifying which elements you want to sign and encrypt. The client and the application can authenticate each other by passing various authentication tokens such as username token, X.509 token, or SAML token.

### Transport-Level Security

Existing technologies such as SSL/TLS can be used to secure the transport channel. SSL allows two applications to securely connect over a network and authenticate each other. It also allows you to encrypt the data exchanged between the applications. In Oracle's Web Services Security model, this transport security mechanism can be used to provide point-to-point security, data integrity, and data confidentiality.

### WS-Security

The Web Services Security (WS-Security) specification describes enhancements to SOAP 1.1 that increase the protection and confidentiality of messages. These enhancements include functionality to secure Simple Object Access Protocol (SOAP) messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens. The goal of the enhancements is to provide greater overall protection for communications over Web services.

WS-Security provides this protection by defining mechanisms for associating tokens with messages. It is completely extensible in that it can support multiple token formats.

The specification includes descriptions of how to include the following security tokens and keys:

- binary security tokens using X.509 and Kerberos ticket

- text-based tokens, such as the username token

- signature and encryption keys

There are no restrictions on the types of credentials that you can include with a message.

Oracle Web Services Security provides support for WS-Security, including XML signature and encryption, and credential propagation through username, X.509, and SAML token profiles. For more information on WS-Security, see the specification at:

`http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss`

### Security Tokens

OracleAS Web Services Security supports the use of the following security tokens.

- Username Token

- X.509 Token

- SAML Token

#### Username Token

The usename token carries basic authentication information. The `username-token` element propagates user name and password information to authenticate the message. The information provided in the token and the trust relationship provide the basis for establishing the identity of the user.

For more information on the username token profile, see the following Web address.

`http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf`

#### X.509 Token

X.509 certificate with the user's credentials can be passed in the SOAP message. The X.509 token can be used to authenticate the user based on the trust relationship. The X.509 token can also be used to sign the SOAP message.

For more information on the X.509 token profile, see the following Web address.

`http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf`

#### SAML Token

SAML security tokens are composed of assertions: one or more statements about a user, such as an authentication or attribute statement. SAML tokens are attached to SOAP messages by placing assertion elements inside the header.

For more information on the SAML token profile, see the following Web address.

`http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf`

#### Keystore

A keystore is used to store certificates, including the certificates of all trusted parties, for use by a program. Through its keystore, an entity, such as OC4J (for example) can authenticate other parties, as well as authenticate itself to other parties. Oracle HTTP Server has what is called a wallet for the same purpose.

OracleAS Web Services Security implementation supports the Java Key Store (JKS) and the Oracle Wallet and PKCS#12 keystore types. You can use Oracle Wallet or JKS as your keystore for storing private keys, public keys, and trusted CA certificates.

Oracle Wallet contains a user private key, a user certificate and a set of trust points (that is, the list of root certificates the user trusts). It implements the storage and retrieval of credentials for use with various cryptographic services. Oracle Wallet files are actually PKCS#12 files, which can be parsed, created, and otherwise, manipulated with the `orapki` tool, Oracle Wallet Manager, and Open SSL.

## Web Services Security Support in OracleAS Web Services

This section contains the following topics.

- Standards Supported by OracleAS Web Services Security

- Interceptor Framework

- Architecture

- Web Service Security Integration

### Standards Supported by OracleAS Web Services Security

OracleAS Web Services Security is defined by the following specifications and standards.

- Web Services Security (WS-Security) defines an open security standard.

  `http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss`

- XML Digital Signature defines how to verify the integrity of an XML object.

  `http://www.w3.org/TR/xmldsig-core`

- XML Encryption defines encrypting XML messages.

  `http://www.w3.org/TR/xmlenc-core`

- SAML tokens assert that the SAML user or subject has already been authenticated.

  `http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf`

- X.509 tokens can be used to authenticate the user based on the trust relationship.

  `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf`

- Username tokens propagates user name and password information.

  `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf`

- Web Service Interoperability (WS-I) is a Web service organization that creates, promotes, and supports generic protocols for the interoperable exchange of messages between Web services.

  `http://www.ws-i.org`

  The following Web Services Interoperability Organization (WS-I) document presents a full discussion of security challenges and threats in today's Web services environment.

  `http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf`.

### Interceptor Framework

In OracleAS Web Services, all WS-Security features, including digital signatures, encryption, and authentication, are implemented using a prebuilt JAX-RPC handler called an interceptor. Whenever a Web service client requests that a message be sent, the SOAP message is "intercepted" by the JAX-RPC handler. The interceptor adds the authentication, signature, and encryption WS-Security elements to the SOAP message, then forwards the message to the receiving Web service.

Each receiving Web service also has interceptors that can decrypt, verify signatures, and authenticate the incoming message.

Figure 1-1 illustrates the actions of the framework. The numbers in the illustration correspond to the following steps.

1. A Web service client sends a message to a Web service. The client interceptor adds the authentication, signature, and encryption WS-Security elements to the outbound SOAP message, then forwards the modified message to the receiving Web service.

2. The service interceptor intercepts the message and decrypts, verifies, and authenticates the message.

3. When sending a response message, the service interceptor in the Web service adds a WS-Security header with integrity and confidentiality.

4. The client interceptor interprets the header and delivers it to the client application.

For more information on common use cases, see Chapter 5, "Secure Web Service Usage Scenarios".

Figure 1-1 Interceptor Framework

Description of "Figure 1-1 Interceptor Framework"

#### Service Security Interceptor

The service security interceptor acts as a filter on incoming SOAP messages. The security settings in the deployment descriptor describes the configuration that drives the interceptor. The service interceptor is responsible for decrypting, verifying, and authenticating (in that order) the incoming request message. When sending a response message, the service interceptor embeds a WS-Security header and provides for integrity and confidentiality of the outbound response message. The main intent of the service interceptor is to establish a security context of execution for SOAP operations

#### Client Security Interceptor

Client handlers act as peers for the service handlers on the Web service client side. The client interceptor follows a set order of processing when it comes to adding authentication tokens to, signing and encrypting a SOAP message.

Figure 1-2 illustrates the movement of data through the client and service handlers. The client handler first collects authentication information and inserts it as WS-Security token. This is followed by signature computation and encryption of the message. Configuration that resides in a Stub deployment descriptor determines what parts of the message must be integrity/confidentiality protected.

Figure 1-2 Data Flow Through Security Handlers

Description of "Figure 1-2 Data Flow Through Security Handlers"

When the Oracle WS-Security runtime is involved in both the client and server, security interceptors are available at both sides, and these intercepts load security policies specified in configuration files. Many other types of clients (for example, .NET clients) understand and generate WS-Security headers within SOAP envelopes. A receiving interceptor enforces security policies; a sending interceptor intercepts a message and modifies it based on security requirements of the target receiver. For example, if the target receiver requires a message to be signed, the sender signs the message.

The Oracle WS-Security component is fully integrated with the OracleAS Web Services security infrastructure, which is based on the J2EE security model. For instance, when a request message contains a user name and password, the security handler authenticates by leveraging the underlying OracleAS JAAS Provider infrastructure. If authentication succeeds, a user identity (JAAS Subject) is established in the execution context, and further resource access is authorized by the container based on this identity. It should be noted that the security interceptor helps establish the identity against which the operation can be authorized. Server-side handlers leverage the OracleAS JAAS Provider for the formulation of Subjects and associate the correct Principal instances (users and/or roles) with each Subject during the commit phase of JAAS authentication. After that point, the asserted or authenticated Principal instances contained in Subject are used as a basis for J2EE and JAAS authorization.

### Architecture

The OracleAS Web Services architecture is built to support secure communications using a declarative model that requires a minimum of developer effort. An interceptor framework automates common security tasks, such as encrypting portions of the message body.

Figure 1-3 illustrates the overall architecture of WS-Security architecture for the Oracle Web service stack.

Figure 1-3 Web Services Security Architecture

Description of "Figure 1-3 Web Services Security Architecture"

The major components of the Oracle WS-Security architecture are the client and service security interceptors. These interceptors plug into the OracleAS Web Services management framework and work in tandem with other interceptors, including those that implement auditing, logging, and reliability.

### Web Service Security Integration

The following sections described how the Web service security interceptor integrates with the OracleAS Web Services Security framework.

- Integration with JAAS

- Integration with Oracle Identity Management

- Integration with External LDAP Servers

- Integration with COREid Access and Identity

#### Integration with JAAS

OracleAS Web Services provides an implementation of Java Authentication and Authorization Service (JAAS) for J2EE applications that is fully integrated with J2EE declarative security. This allows J2EE applications to take advantage of the JAAS constructs such as principal-based security and pluggable login modules. OracleAS Web Services Security provides out-of-the-box JASS authentication login modules that allow J2EE applications running on OracleAS Web Services to leverage the central security services of Oracle Identity Management.

The JAAS Provider ensures secure access to and execution of Java applications, and integration of Java-based applications with Oracle Application Server Single Sign-On.

#### Integration with Oracle Identity Management

Oracle Identity Management provides an enterprise infrastructure for securing distributed enterprise applications. Oracle Identity Management is an integrated package of the Oracle Internet Directory, an LDAP server, Single Sign-On, Security and User Management functionality. For more information on these components, see the books Oracle Identity Management and the Oracle Identity Management Administrator's Guide.

Security in OracleAS Web Services is integrated with Oracle Identity Management. With this integration it is possible to perform the following services:

- Secure Web services and authenticate against OID servers.

- Propagate the Oracle Single Sign-On server authenticated user identity to remote Web services using standards based SAML token.

- Implement fine-grained JAAS authorization for Web services. In this case, JAAS authorization policies are stored in the OID server.

##### Oracle Identity Management Support for Web Services Authentication Mechanisms

Oracle Identity Management integration supports these Web services authentication mechanisms: HTTP basic, digest, username token, X.509 token, and SAML token.

##### Application Server Web Services Security Integration with Oracle Identity Management

The current release of Application Server Web Services Security is integrated with these releases of Oracle Identity Management: 9.0.4, 10.1.2.0.1, and 10.1.2.0.2.

For more information on integrating Oracle Identity Management with OC4J Security, see the Oracle Containers for J2EE Security Guide.

#### Integration with External LDAP Servers

Web services security in OracleAS Web Services is integrated with external (non-Oracle) LDAP servers such as Active Directory. With this integration it is possible to:

- Secure Web services and authenticate against LDAP servers.

- Implement fine-grained JAAS authorization for Web services. In this case, JAAS authorization policies are stored in the XML file `system-jazn-data.xml`.

##### External LDAP Server Integration Support for Web Services Authentication Mechanisms

External LDAP server integration supports these Web services authentication mechanisms: HTTP basic, username token, X.509 token, and SAML token.

##### Application Server Web Services Security Integration with External LDAP Servers

The current release of Application Server Web Services Security can be integrated with these external LDAP servers:

- 10.1.3 Application Server Web Services Security is integrated with Windows 2000 and 2003 Active Directory.

- 10.1.3 Application Server Web Services Security is integrated with Sun Java System Application Server (formerly known as iPlanet).

For more information on integrating Oracle Identity Management with OC4J security, see the Oracle Containers for J2EE Security Guide.

#### Integration with COREid Access and Identity

Oracle COREid Access and Identity is a complete solution for user identity and profile management, single sign-on, and access control. By integrating COREid with OC4J, a single COREid instance allows you to centralize authentication and authorization for one or more instances of OC4J. This single instance allows you to access single sign-on, centralize auditing, and provide stronger authentication options.

The COREid security provider for OC4J can be used to configure authentication and authorization for Web-based applications and single sign-on. It can also be used to configure EJB authentication and Web Service authentication schemes such as username token, X509 and SAML. See the Oracle Containers for J2EE Security Guide for more information on Oracle COREid Access and Identity.

## Tool Support for Web Service Security

This section provides an overview of the parts of the Web service security configuration that can be set by the JDeveloper and Application Server Control tools. For detailed information of the individual security options that can be controlled by these tools, see the on-line help for Application Server Control and JDeveloper.

This section contains these sub-sections:

- Application Server Control Support for Web Service Security

- JDeveloper Support for Web Service Security

- Oracle Web Services Manager

### Application Server Control Support for Web Service Security

Application Server Control can read and modify the security configuration of a deployed Web service. Once the configuration values have been modified and applied, the Web service can be restarted and run with the new values. Application Server Control can be used to set Web service security options on the port and operation level.

At the global level, you can use Application Server Control to set the keystore configuration and the signature and encryption keys. Like the security configuration, if you change the keystore, signature, or encryption values, you must restart the application for the new values to take effect.

For more information on how to use Application Server Control to read and modify the configuration of a deployed Web service, see the Application Server Control on-line help.

#### Global- and Port-Level Keystore and Identity Certificates

You can choose to employ a global keystore or an application-specific keystore for the Web service port. If you choose a global keystore, it applies to all applications deployed in that OC4J instance. If you choose an port-specific keystore, it must be deployed with your application. For a global keystore, you choose a keystore name, path, and password. You also choose identity certificates for message signature and encryption. For more information on the elements and attributes that allow you to specify a global keystore, see "Keystore Elements".

If you choose an application-specific keystore, you must also specify the identity certificates for signature and encryption to be used by all operations exposed by this Web service port. For more information on the elements and attributes that allow you to specify a port signature and encryption keys, see "Signature and Encryption Key Elements".

Note: Both server and trusted certificates are stored in the same keystore. This is different from how Secure Sockets Layer (SSL) or Oracle Remote Method Invocation (ORMI) is used in OC4J. You can use either Oracle Wallet or Java Keystore (JKS) as a keystore. "Using Keystores" provides more information on how to use these keystores.

#### Port- and Operation-Level Security Configuration

A security configuration for inbound and outbound SOAP messages can be set on the port-level and operation level. The same security operations (except keystore settings) are available at operation level.

A port-level setting applies to a Web service application. A port-level security configuration is used by all of the operations exposed by the Web service port. An operation-level setting is for a particular operation of the Web service application. A configuration setting made on the operation level overrides the setting made on the port level.

At the port-level you also choose keystore and identity certificates that will apply to the all of the operations on the Web service. These values cannot be overridden on the operation level.

#### Port-Level and Operation-Level Inbound Policy Configuration

The port and operation level share the same security options for inbound SOAP messages. This section summarizes the options that Application Server Control can set.

- Authentication for inbound messages—lets you specify whether the Web service should expect the message to authenticate by using a username/password (with or without a nonce or timestamp), a X.509 certificate, or a SAML token. "Security Elements for Inbound Messages" provides more information on the authentication elements that Application Server Control can set.

- Signature verification for inbound messages—lets you specify whether to require the message body to be signed, whether a timestamp is present and a set of acceptable signature algorithms. "Signature Verification Elements for Inbound Messages" provides more information on the verification elements that Application Server Control can set.

- Decryption for inbound messages—lets you specify whether the message body should be encrypted and a set of acceptable encryption algorithms. "Decryption Elements for Inbound Messages" provides more information on the decryption elements that Application Server Control can set.

#### Port- and Operation-Level Outbound Policy Configuration

The port and operation level share the same security options for outbound messages. This section summarizes the options that Application Server Control can set.

- Signing for outbound messages—lets you specify whether to sign the message, add a timestamp, and an acceptable signature algorithm. "Signature Elements for Outbound Messages" provides more information on the signing elements that Application Server Control can set.

- Encryption for outbound messages—lets you specify to encrypt the body element of the outbound SOAP message by using either a request certificate or a public key by specifying an alias. "Encryption Elements for Outbound Messages" provides more information on the verification elements that Application Server Control can set.

### JDeveloper Support for Web Service Security

JDeveloper can be used to develop OracleAS Web Services and client Web service management configuration files. JDeveloper can aid you in the initial creation of these files or it can be used to add management configuration to existing files.

Wizards in JDeveloper help you configure port and operation level security for inbound and outbound SOAP messages. They cannot be used to set security on the global level.

The port and operation level share the same security options for inbound and outbound messages. This section summarizes the options that JDeveloper wizards can set. For more information on these options, see the JDeveloper on-line help.

- Web service authentication—lets you specify whether the Web service should expect to be accessed via a username and password, a X.509 certificate, or a SAML token.

- signature validation for inbound messages—lets you specify that inbound messages must be signed, and the signature algorithm.

- decryption for inbound messages—lets you specify that inbound messages will be decrypted and the decryption algorithm.

- signing outbound messages—lets you specify whether to add signatures and timestamps to outbound messages and a signing algorithm.

- encryption for outbound messages—lets you specify whether to use a public key or the client-supplied certificate from a previously sent signed message, and the encryption algorithm.

- keystore path—lets you specify credential store locations of the various keys required to implement the chosen security policies.

- signature key—lets you specify the alias and password to access the required key for signing messages.

- encryption key—lets you specify the alias and password to access the required key for decrypting messages.

### Oracle Web Services Manager

Oracle Web Services Manager (OWSM) is a Web services security and management solution that provides the visibility and control required to deploy Web services into production. With OWSM, organizations can enjoy a common security infrastructure for all Web Service applications. This allows "best practice" security policies and monitoring to be deployed across existing or new services.

For information on integrating OWSM with OC4J, see the Oracle Web Services Manager Installation and Deployment Guide.

With OWSM, an administrator creates security and management policies using a browser-based tool. A typical Web Service security policy could include the following items:

- Decrypt the incoming XML message

- Extract the user's credentials

- Perform an authentication for this user

- Perform an authorization check for this user and this Web Service

- Write a log record of the above information

- If all steps are successful, pass the message to the intended Web Service

- If all of the steps are not successful, return an error and write an exception record

To apply the security policy, OWSM intercepts every incoming request to a Web service and apply any one of the policy items listed above. As the policy is executed, OWSM collects statistics about its operations and sends them to a monitoring server. The monitor displays errors, service availability data, and so on. As a result, each Web service in an enterprise network can automatically gain security and management control, without the service developer coding extra logic.

For more information on using Oracle Web Services Manager, see the Oracle Web Services Manager User and Administrator Guide.

The following sections describe the motivations for using OWSM.

Web Services Access Control and Single Sign-On

OWSM supports single sign-on, including authentication, authorization, and auditing for Web services. For example, a browser-based single sign-on cookie could be used for authentication and authorization in a Web service. OWSM has tight integration with products such as Siteminder and COREid to support enterprise single sign-on solutions. It also supports authentication and authorization through Microsoft Active Directory, and LDAP.

Centralized Security Policy Management with Localized Enforcement

OWSM allows organizations to minimize the duplication of effort required to build security into each service by leveraging a centralized security infrastructure. The Oracle Web service management solution provides the ability to add "best practice" security to an existing Web service, without requiring you to re-work the Service's code.

Place Security Policies in the hands of Security Professionals instead of the Developer

Companies are struggling to manage their security policies. They want to be able to change, develop, and manage their security policies from a central location. This reduces cost, and allows an organization to quickly determine their security policies throughout their applications.

#### When to Use OWSM to Secure Web Services

Both OWSM and OracleAS Web Services Security provide the ability to secure Web services. The WS-Security implementation within OracleAS Web Services was developed so that Web services can be secured by anybody who uses them. OracleAS Web Services Security is bundled with Oracle 10.1.3 Application Server release, and supports the WS-Security 1.0 specification. It is ideal for deployments where Web services are deployed within the OC4J instance, and security is enforced locally by OC4J.

For large or enterprise-wide deployments where a number of Web services must be centrally managed and secured, then OWSM is recommended.