9 Configuring Policies

This chapter discusses how to configure policies in Web services and Web service clients to achieve Quality of Service (QoS) requirements. It also describes the related Oracle WebLogic Server configuration and setup required to use these policies.

The predefined policies are described in Appendix B, "Predefined Policies". This Appendix is the definitive source of information for the format of the policies. Some information from the Appendix is repeated here for your convenience.

This chapter includes the following sections:

Determining Which Security Policies to Use

Use the following series of questions to help you identify the security policies that best meet your requirements:

  1. What are the basic requirements of your security policy? Decide if you need to only authenticate users, or if you only need message protection, or if you need both.

    1. Do you require authentication only? If yes, then go to step 2.

    2. Do you require authorization only? If yes, then see "Authorization Policies"

    3. Do you require authentication and authorization? If yes, then go to step 3.

    4. Do you only require message protection? If yes, then see "Message Protection-Only Policies and Configuration Steps".

    5. Do you require both authentication and message protection? If yes, then go to step 4.

  2. If you only require authentication, then there are two basic questions you need to consider:

    1. Where will the token be inserted? Will the token to be inserted in the transport layer or in a SOAP header?

    2. Do you need to use a particular type of token? The supported credentials for authentication-only policies are username/password, SAML, and Kerberos tokens.

  3. If you require authentication and authorization, then you need to consider the following:

    1. Review the considerations provided for authentication in step 2.

    2. Review "Authorization Policies" for more information about authorization policies.

  4. If you require both authentication and message protection, then you need to consider the following:

    1. Will message protection be handled in the transport layer? If yes, then there are four sets of policies to choose from: Username over SSL, SAML over SSL (Sender-Vouches), SAML over SSL (Token Bearer), and HTTP token over SSL.

      In one set of policies (wss_http_token_over_ssl_client_policy and wss_http_token_over_ssl_service_policy) authentication is also handled in the transport layer. For the other three polices, authentication takes place in the SOAP header.

      If you are using the WS-Security V1.0 or V1.1 standard, then both authentication and message protection occur in the SOAP header. There are five pairs of policies supporting the following tokens: username/password, SAML, and X.509 certificates.

      For more information, see "Message Protection and Authentication Policies and Configuration Steps".

Protecting Messages

Message protection involves encrypting the message for message confidentiality and signing the message for message integrity. Oracle Fusion Middleware predefined policies and any policy you create using one of the message-protection assertion templates provide the options for message confidentiality, message integrity, or both.

The following steps summarizes what you must do in order to configure the clients and services for message protection:

  • Attach the appropriate message protection policy to each of the clients and services.

  • If you want message integrity, then the message must be signed.

  • If you want message confidentiality, then the message must be encrypted.

  • Add the required public and private keys to the keystores of the clients and services. This step requires you to configure the keystore, as described in "Setting up the Keystore for Message Protection".

Message Protection Basics

Message protection encompasses two concepts, message confidentiality and message integrity.

Message confidentiality involves keeping the data secret, as well as the identities of the sending and receiving parties. Confidentiality is achieved by encrypting the content of messages and obfuscating the identifies of the sending and receiving parties. The sender uses the recipient's public key to encrypt the message. Only the recipient's private key can successfully decrypt the message, ensuring that it cannot be read by third parties while in transit. This process requires that the sender's keystore already contain a digital certificate containing the recipient's public key.

Message integrity is achieved by having an authority digitally sign the message. Digital signatures are used to authenticate the sender of the SOAP message and to ensure the integrity of the SOAP message (that is, to ensure that the SOAP message is not altered while in transit).

When a digital signature is applied to a SOAP message, a unique hash is produced from the message, and this hash is then encrypted with the sender's private key. When the message is received, the recipient decrypts the hash using the sender's public key.

Note:

Generally, the recipient does not need to have the sender's public key in its keystore to validate the certificate. It is sufficient to have the root certificate in the keystore to verify the certificate chain. However, if the sender's public key is not present in the message, as in the case of the Thumbprint and SerialIssuer mechanisms, the sender's public key must be in the recipient's keystore.

This serves to authenticate the sender, because only the sender could have encrypted the hash with the private key. It also serves to ensure that the SOAP message has not been tampered with while in transit, because the recipient can compare the hash sent with the message with a hash produced on the recipient's end.

The message-protection assertion templates and predefined policies can be used to protect request and response messages by doing the following:

  • Signing messages

  • Encrypting messages

  • Signing and encrypting messages

  • Decrypting messages

  • Verifying signatures

  • Decrypting messages and verifying signatures

The Fusion Middleware Control user interface for the predefined message protection policies makes it easy to specify which message parts are signed, encrypted, or both, as shown in Figure 9-1. You can require that the entire body be signed, encrypted, or both, or identity specific header and body elements.

Figure 9-1 The Signing and Encryption Portion of Message Protection Policies

Description of Figure 9-1 follows
Description of "Figure 9-1 The Signing and Encryption Portion of Message Protection Policies"

Security SwA Attachments

Packaging as attachments in SOAP messages has become a norm in the Web Services area for any data that cannot be placed inside SOAP Envelope. The primary SOAP message can reference additional entities as attachments or attachments with MIME headers.

Each SwA attachment is a MIME part and contains the MIME header. Include Attachment signs the attachment but not the MIME header corresponding to that. Include Attachment with MIME Headers signs the attachments as well as the MIME headers.

Which Policies Offer Message Protection?

The following policies offer message protection. The subsequent sections for each of these policies later in this chapter describe how each policy implements message protection.

  • oracle/wss10_message_protection_client_policy

  • oracle/wss10_message_protection_service_policy

  • oracle/wss10_username_id_propagation_with_msg_protection_client_policy

  • oracle/wss10_username_id_propagation_with_msg_protection_service_policy

  • oracle/wss10_username_token_with_message_protection_client_policy

  • oracle/wss10_username_token_with_message_protection_service_policy

  • oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

  • oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy

  • oracle/wss10_x509_token_with_message_protection_client_policy

  • oracle/wss10_x509_token_with_message_protection_service_policy

  • oracle/wss10_saml_token_with_message_protection_client_policy

  • oracle/wss10_saml_token_with_message_protection_service_policy

  • oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

  • oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy

  • oracle/wss11_message_protection_client_policy

  • oracle/wss11_message_protection_service_policy

  • oracle/wss11_kerberos_token_with_message_protection_client_policy

  • oracle/wss11_kerberos_token_with_message_protection_service_policy

  • oracle/wss11_saml_token_with_message_protection_client_policy

  • oracle/wss11_saml_token_with_message_protection_service_policy

  • oracle/wss11_username_token_with_message_protection_client_policy

  • oracle/wss11_username_token_with_message_protection_service_policy

  • oracle/wss11_x509_token_with_message_protection_client_policy

  • oracle/wss11_x509_token_with_message_protection_service_policy

Both the WS-Security 1.0 and WS-Security 1.1 standards are supported. Use the assertion template or predefined policy that supports the standard which both the Web service and client share in common. If you are starting anew, use the WS-Security 1.1 standard because it provides more options and requires less PKI deployment.

The assertion templates support partial signing and encryption as well as full signing and encryption of the message body. For those assertion templates or predefined policies that provide SOAP message protection, the default behavior is to protect the entire SOAP message body by signing and encrypting the entire SOAP body. You can configure the assertions and policies to protect selected elements, if you wish.

Configuring Keystores for SSL

If you want to use any of the policies listed in "Which Policies Require You to Configure SSL?" or "Which Policies Require You to Configure Two-Way SSL?", you must configure keystores for SSL.

SSL provides secure connections by allowing two applications connecting over a network to authenticate the other's identity and by encrypting the data exchanged between the applications.

Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient. A client certificate (two-way SSL) can be used to authenticate the user.

This section describes how to set up a Web service client and the WebLogic Server Web service container to send requests over SSL.

In order to use SSL in a Web service application, you need to:

  • Configure the WebLogic Server keystore and SSL settings.

  • Configure the Web service client keystore and SSL settings.

These steps are described in the sections that follow.

Which Policies Require You to Configure SSL?

The predefined policies that require you to configure SSL are as follows:

  • oracle/wss_http_token_over_ssl_service_policy

  • oracle/wss_http_token_over_ssl_client_policy

  • oracle/wss_saml_token_bearer_over_ssl_server_policy

  • oracle/wss_saml_token_bearer_over_ssl_client_policy

  • oracle/wss_saml_token_over_ssl_service_policy

  • oracle/wss_saml_token_over_ssl_client_policy

  • oracle/wss_username_token_over_ssl_service_policy

  • oracle/wss_username_token_over_ssl_client_policy

In addition, you can create a new policy that requires SSL by using the following templates:

  • oracle/wss_http_token_over_ssl_service_template

  • oracle/wss_http_token_over_ssl_client_template

  • oracle/wss_saml_token_bearer_over_ssl_service_template

  • oracle/wss_saml_token_bearer_over_ssl_client_template

  • oracle/wss_saml_token_over_ssl_service_template

  • oracle/wss_saml_token_over_ssl_client_template

  • oracle/wss_username_token_over_ssl_service_template

  • oracle/wss_username_token_over_ssl_client_template

See Appendix C, "Predefined Assertion Templates" and Appendix B, "Predefined Policies" for more information on these assertions and policies.

Which Policies Require You to Configure Two-Way SSL?

The predefined policies that require you to configure two-way SSL are as follows:

  • oracle/wss_saml_token_over_ssl_client_policy

  • oracle/wss_saml_token_over_ssl_service_policy

  • oracle/wss_username_token_over_ssl_client_policy, when mutual authentication is selected.

  • oracle/wss_username_token_over_ssl_service_policy, when mutual authentication is selected.

  • oracle/wss_http_token_over_ssl_client_policy, when mutual authentication is selected.

  • oracle/wss_http_token_over_ssl_service_policy, when mutual authentication is selected.

In addition, you can create a new policy that requires two-way SSL by using the following templates:

  • oracle/wss_saml_token_over_ssl_client_template

  • oracle/wss_saml_token_over_ssl_service_template

How to Configure a Keystore on WebLogic Server

Private keys, digital certificates, and trusted certificate authority certificates establish and verify identity and trust in the WebLogic Server environment.

This section briefly summarizes the steps that are required to configure the keystore in WebLogic Server. See the following two sources for complete information:

WebLogic Server is configured with a default identity keystore DemoIdentity.jks and a default trust keystore DemoTrust.jks. In addition, WebLogic Server trusts the certificate authorities in the cacerts file in the JDK. This default keystore configuration is appropriate for testing and development purposes. However, these keystores should not be used in a production environment.

To configure identity and trust for a server:

  1. Obtain digital certificates, private keys, and trusted CA certificates from Sun Microsystem's keytool utility, or a reputable vendor such as Entrust or Verisign, and include them in the keystore.

    To get the certificate, you must create a Certificate Request and submit it to the CA. The CA will authenticate the certificate requestor and create a digital certificate based on the request.

    The PEM (Privacy Enhanced Mail) format is the preferred format for private keys, digital certificates, and trusted certificate authorities (CAs).

    If you use the keytool utility, the default key pair generation algorithm is Digital Signature Algorithm (DSA). WebLogic Server does not support DSA. Specify another key pair generation and signature algorithm such as RSA when using WebLogic Server. For more information about Sun's keytool utility, see the keytool-Key and Certificate Management Tool description at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html.

    You can also use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit. The demonstration digital certificates, private keys, and trusted CA certificates should be used only in a development environment.

  2. Create one keystore for identity and one for trust. The preferred keystore format is JKS (Java KeyStore).

  3. Load the private keys and trusted CAs into the keystores.

  4. In the left pane of the Console, expand Environment and select Servers.

  5. Click the name of the server for which you want to configure the identity and trust keystores.

  6. Select Configuration, and then Keystores.

  7. In the Keystores field, select the method for storing and managing private keys/digital certificate pairs and trusted CA certificates. These options are available:

    • Custom Identity and Custom Trust: Identity and trust keystores you create.

    • Demo Identity and Demo Trust: The demonstration identity and trust keystores, located in the ..\server\lib directory and the JDK cacerts keystore, are configured by default. Use for development only.

    • Custom Identity and Java Standard Trust: A keystore you create and the trusted CAs defined in the cacerts file in the JAVA_HOME\jre\lib\security directory.

    • Custom Identity and Command Line Trust: An identity keystore you create and command-line arguments that specify the location of the trust keystore.

  8. In the Identity section, define attributes for the identity keystore.

    • Custom Identity Keystore: The fully qualified path to the identity keystore.

    • Custom Identity Keystore Type: The type of the keystore. Generally, this attribute is Java KeyStore (JKS); if left blank, it defaults to JKS.

    • Custom Identity Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.

      Note:

      The passphrase for the Demo Identity keystore is DemoIdentityKeyStorePassPhrase.
  9. In the Trust section, define properties for the trust keystore.

    If you chose Java Standard Trust as your keystore, specify the password defined when creating the keystore. Confirm the password.

    If you chose Custom Trust, define the following attributes:

    • Custom Trust Keystore: The fully qualified path to the trust keystore.

    • Custom Trust Keystore Type: The type of the keystore. Generally, this attribute is JKS; if left blank, it defaults to JKS.

    • Custom Trust Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore, so whether or not you define this property depends on the requirements of the keystore.

  10. The changes are automatically activated.

Configuring SSL on WebLogic Server (One-Way)

With one-way SSL, the server is required to present a certificate to the client but the client is not required to present a certificate to the server.

After you configure identity and trust keystores for a WebLogic Server instance as described in "Configuring Keystores for SSL", you configure its SSL attributes. These attributes describe the location of the identity key and certificate in the keystore specified on the Configuration: Keystores page. Use the Configuration: SSL page to specify this information.

This section summarizes the steps required to configure SSL on WebLogic Server. For complete information, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

To configure SSL:

  1. In the left pane of the WebLogic Server Administration Console, expand Environment and select Servers.

  2. Click the name of the server for which you want to configure SSL.

  3. Select Configuration, and then the SSL page, and choose the location of identity (certificate and private key) and trust (trusted CAs) for WebLogic Server.

  4. Set SSL attributes for the private key alias and password.

  5. At the bottom of the page, click Advanced.

  6. Set Hostname Verification to None.

  7. Indicate the number of times WebLogic Server can use an exportable key between a domestic server and an exportable client before generating a new key. The more secure you want WebLogic Server to be, the fewer times the key should be used before generating a new key.

  8. Set the Two Way Client Cert Behavior control to Client Certs Not Requested.

  9. Specify the inbound and outbound SSL certificate validation methods. These options are available:

    • Builtin SSL Validation Only: Uses the built-in trusted CA-based validation. This is the default.

    • Built-in SSL Validation and Cert Path Validators: Uses the built-in trusted CA-based validation and uses configured CertPathValidator providers to perform extra validation.

Configuring SSL on WebLogic Server (Two-Way)

With two-way SSL, the server presents a certificate to the client and the client presents a certificate to the server. WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL handshake.

After you configure identity and trust keystores for a WebLogic Server instance as described in "Configuring Keystores for SSL", you can configure its two-way SSL attributes if the policy or template you are using requires it, as described in "Which Policies Require You to Configure Two-Way SSL?".

This section summarizes the steps required to configure SSL on WebLogic Server. For complete information, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

To configure two-way SSL:

  1. In the left pane of the WebLogic Server Administration Console, expand Environment and select Servers.

  2. Click the name of the server for which you want to configure SSL.

  3. Select Configuration, and then the SSL page, and choose the location of identity (certificate and private key) and trust (trusted CAs) for WebLogic Server.

  4. Set SSL attributes for the private key alias and password.

  5. At the bottom of the page, click Advanced.

  6. Set Hostname Verification to None.

  7. Indicate the number of times WebLogic Server can use an exportable key between a domestic server and an exportable client before generating a new key. The more secure you want WebLogic Server to be, the fewer times the key should be used before generating a new key.

  8. Set the Use Server Certs control if needed. Setting this control determines whether a Web service client hosted on WebLogic Server should use the server certificates/key as the client identity when initiating a connection over HTTPS.

  9. Set the Two Way Client Cert Behavior control to Client Certs Requested and Enforced.

  10. Specify the inbound and outbound SSL certificate validation methods. These options are available:

    • Builtin SSL Validation Only: Uses the built-in trusted CA-based validation. This is the default.

    • Builtin SSL Validation and Cert Path Validators: Uses the built-in trusted CA-based validation and uses configured CertPathValidator providers to perform extra validation.

Configuring SSL for a Web Service Client

The core WebLogic Server security subsystem uses private key and X.509 certificate pairs, stored in the default keystores, for SSL.

You must ensure that the Web Service client trusts the X.509 certificate that WebLogic Server uses to digitally sign the request. Do one of the following:

  1. Ensure that WebLogic Server obtains a digital certificate that the client automatically trusts, because it has been issued by a trusted certificate authority.

  2. Create a certificate registry that lists all the individual certificates trusted by WebLogic Server, and then ensure that the client trusts these registered certificates.

To configure SSL for a Web service client:

  1. Create a keystore used by the client application. Oracle recommends that you create one client keystore per application user.

    You can use the keytool utility to perform this step. For development purposes, the keytool utility is the easiest way to get started.

  2. Create a private key and digital certificate pair, and load it into the client keystore.

    Make sure that the certificate's key usage allows both encryption and digital signatures. Oracle requires a key length of 1024 bits or larger.

  3. Make sure that the following properties are set in the client's JVM:

    • javax.net.ssl.trustStore -- The name of the file that contains the trust store.

    • javax.net.ssl.trustStoreType -- The type of KeyStore object that you want the default TrustManager to use.

    • javax.net.ssl.trustStorePassword -- The password for the KeyStore object that you want the default TrustManager to use.

Configuring Two-Way SSL for a Web Service Client

You must ensure that WebLogic Server is able to validate the X.509 certificate that the client uses to digitally sign its request, and that WebLogic Server in turn uses to encrypt its responses to the client. Do one of the following:

  1. Ensure that the client application obtains a digital certificate that WebLogic Server automatically trusts, because it has been issued by a trusted certificate authority.

  2. Create a certificate registry that lists all the individual certificates trusted by WebLogic Server, and then ensure that the client uses one of these registered certificates.

To configure SSL for a Web service client:

  1. Create a keystore used by the client application. Oracle recommends that you create one client keystore per application user.

    You can use the keytool utility to perform this step. For development purposes, the keytool utility is the easiest way to get started.

  2. Create a private key and digital certificate pair, and load it into the client keystore.

    Make sure that the certificate's key usage allows both encryption and digital signatures. Oracle requires a key length of 1024 bits or larger.

  3. Make sure that the following properties are set in the client's JVM:

    • javax.net.ssl.trustStore -- The name of the file that contains the trust store.

    • javax.net.ssl.trustStoreType -- The type of KeyStore object that you want the default TrustManager to use.

    • javax.net.ssl.trustStorePassword -- The password for the KeyStore object that you want the default TrustManager to use.

    • javax.net.ssl.keyStore -- The name of the file that contains the KeyStore object.

    • javax.net.ssl.keyStoreType -- The type of KeyStore object.

    • javax.net.ssl.keyStorePassword -- The password for the KeyStore.

Setting up the Keystore for Message Protection

In order to sign and encrypt SOAP messages you must first create and configure the Web Services Manager Keystore for a WebLogic domain. This keystore is used to store public and private keys for SOAP messages within the WebLogic Domain.

Note:

The Web services manager runtime does not use the WebLogic Server keystore that is used for SSL as documented elsewhere in this chapter.

The signature and encryption keys are used to sign, verify, encrypt, and decrypt the SOAP messages.

The keystore configuration is domain wide: all Web services and Web service clients in the domain use this keystore.

To set up the keystore used by Web Services Manager follow these steps:

  1. Use the keytool to create a Java keystore, as described in "How to Create and Use a Java Keystore".

  2. In the navigator pane, expand WebLogic Domain to show the domain for which you need to configure the keystore. Select the domain.

  3. Using Fusion Middleware Control, click Weblogic Domain, then Security, and then Security Provider Configuration.

    Click the plus sign (+) to expand the Keystore control near the bottom of the page, then click Configure.

    The Web Services Manager Keystore Configuration page is displayed, as shown in Figure 9-2.

    Figure 9-2 Web Services Manager Keystore Configuration

    Description of Figure 9-2 follows
    Description of "Figure 9-2 Web Services Manager Keystore Configuration"

  4. If it is not already enabled, click the Configure Keystore Management check box.

  5. Enter the path and name for the keystore that you created. By default, the keystore name is default-keystore.jks, but you can change this. However, you cannot change the keystore type; it must be JKS.

  6. Enter a password for the keystore and confirm it.

  7. Enter an alias and password for the signature and encryption keys. Confirm the passwords.

    The alias and password for the signature and encryption keys define the string alias and password used to store and retrieve the keys.

  8. Click OK to submit the changes.

    Note that all fields on this page require a restart of Oracle Enterprise Manager Fusion Middleware Control to take effect.

Setting Up the Web Service Client Keystore at Design Time

You need to create a Java Key Store (JKS) keystore to store the signature and encryption keys required by the X.509 token on the client. Keys are used for a variety of purposes, including authentication and data integrity. For example:

  • To sign data, you must have the signer's private key.

  • To verify a signature, you must have a trusted CA certificate and the public key that matches the private key.

  • To encrypt data, you must have the recipient's public key.

  • To decrypt data, you must have the private key which corresponds to the public key.

These trusted certificates and public and private keys are stored in the keystore. The following sections describe where you can obtain trusted certificates and how to create and use these keystores.

How to Obtain a Trusted Certificate

You can obtain a certificate from a Certificate Authority (CA), such as Verisign or Entrust, and include them in the keystore. To get the certificate, you must create a Certificate Request and submit it to the CA. The CA will authenticate the certificate requestor and create a digital certificate based on the request.

How to Create and Use a Java Keystore

The Java Keystore (JKS) is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility. You can use the keytool utility to perform the following tasks:

  • Create public and private key pairs, designate public keys belonging to other parties as trusted, and manage your keystore.

  • Issue certificate requests to the appropriate Certification Authority (CA), and import the certificates which they return.

  • Administer your own public and private key pairs and associated certificates. This allows you to use your own keys and certificates to authenticate yourself to other users and services. This process is known as "self-authentication." You can also use your own keys and certificates for data integrity and authentication services, using digital signatures.

  • Cache the public keys of your communicating peers. The keys are cached in the form of certificates.

How to Create Private Keys and Load Trusted Certificates

The following section provides an outline of how to create and manage the JKS with the keytool utility. It describes how to create a keystore and to load private keys and trusted CA certificates. You can find more detailed information on the commands and arguments for the keytool utility at this Web address.

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

  1. Create a new private key and self-signed certificate.

    Use the genKey command to create a private key. It will create a new private key if one does not exist. The following command generates an RSA key, with RSA-SHA1 as the signature algorithm, with the alias test in the test.jks keystore.

    keytool -genkey -alias test -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, C=US" -keystore test.jks

    The keytool utility prompts for the needed key and keystore passwords. DSA key is not supported. Make sure you pass the parameter " -keyalg RSA " in the command.

  2. Display the keystore.

    The following command displays the contents of the keystore. It will prompt you for the keystore password.

    keytool -list -v -keystore test.jks

  3. Import a trusted CA certificate in the keystore.

    Use the -import command to import the certificate. The following command imports a trusted CA certificate into the test.jks keystore. It will create a new keystore if one does not exist. The keytool utility prompts for the needed password.

    keytool -import -alias aliasfortrustedcacert -trustcacerts -file trustedcafilename -keystore test.jks

  4. Generate a certificate request.

    Use the -certreq command to generate the request. The following command generates a certificate request for the test alias. The CA will return a certificate or a certificate chain.

    keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore test.jks

  5. Replace the self-signed certificate with the trusted CA certificate.

    You must replace the existing self-signed certificate with the certificate from the CA. To do this, use the -import command. The following command replaces the trusted CA certificate in the test.jks keystore. The keytool utility prompts for the needed password.

    keytool -import -alias test -file trustedcafilename -keystore test.jks

Configuring the Credential Store Provider

The credential store provider provides a way to store, retrieve, and delete credentials for a Web service and other applications.

For example, the oracle/wss_http_token_client_policy policy includes the csf-key property, with a default value of basic.credentials. This credential is stored in the credential store provider.

Follow these steps to configure the credential store provider:

  1. In the navigator pane, expand WebLogic Domain to show the domain for which you need to configure the keystore. Select the domain.

  2. Using Fusion Middleware Control, click Weblogic Domain, then Security, and then Credentials.

    The Credential Store Provider Configuration page is displayed, as shown in Figure 9-3. (In this figure, the Credential Store Provider control has already been expanded.)

    Figure 9-3 Credential Store Provider Configuration Page

    Description of Figure 9-3 follows
    Description of "Figure 9-3 Credential Store Provider Configuration Page"

  3. Click Create Map and enter the map name oracle.wsm.security, as shown in Figure 9-4.

    Figure 9-4 Set Security Provider Screen

    Description of Figure 9-4 follows
    Description of "Figure 9-4 Set Security Provider Screen"

  4. Click Create Key. The Create Key dialog box appears, as shown in Figure 9-5.

    Figure 9-5 Create Key Dialog Box

    Description of Figure 9-5 follows
    Description of "Figure 9-5 Create Key Dialog Box"

  5. Select the map name oracle.wsm.security if it is not already selected.

  6. Enter the key name.

  7. Select the key type, either Password or Generic. A password credential can store a username and password. A generic credential can store any credential object.

  8. For a password credential, enter the username and password.

  9. Click OK.

Configuring an Authentication Provider in WebLogic Server

This section introduces WebLogic Server security features that are described in detail in Oracle Fusion Middleware Securing Oracle WebLogic Server and in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help. This section provides only a brief introduction to the security features, and concentrates on how they relate to configuring policies.

The security policies that you use determine what types of security providers you must configure in WebLogic Server. You can categorize the policies based on their token type:

  • Policies that use the username token require an authentication provider that can handle the NameCallback and PasswordCallback. The WebLogic Default Authentication provider is one such provider, as is the OAM Authentication provider.

    The following policies fall into this category:

    • oracle/wss_http_token_service_policy

    • oracle/wss_username_token_service_policy

    • oracle/wss_username_token_over_ssl_service_policy

    • oracle/wss11_username_token_with_message_protection_service_policy

    • oracle/wss10_username_token_with_message_protection_service_policy

    • oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy

  • Policies that use the X.509 and SAML tokens require an authentication provider (or Identity Assertion provider) that can handle perimeter authentication via the NameCallback. The Web service runtime process the tokens on your behalf to determine the username, and then invokes the Oracle Platform Security Service (OPSS) layer to complete the authentication. In this way, the security providers do not handle the X.509 or SAML tokens directly, and the WebLogic providers do not have to support these token types.

    The following policies fall into this category:

    • oracle/wss10_x509_token_with_message_protection_service_policy

    • oracle/wss10_saml_token_service_policy

    • oracle/wss10_saml_token_with_message_protection_service_policy

    • oracle/wss_saml_token_over_ssl

    • oracle/wss_saml_token_bearer_over_ssl_service_policy

    • oracle/wss10_saml_hok_token_with_message_protection_service_policy

    • oracle/wss11_saml_token_with_message_protection_service_policy

    • oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy

    • oracle/wss11_x509_token_with_message_protection_service_policy

  • Policies that use the ObossoCookie token must use the OAM Identity Asserter because it is the only provider that handles this token type.

    Only the oracle/wss_oam_token_service_policy policy falls into this category.

What Type of WebLogic Security Authentication Providers Must You Create?

The only specific WebLogic security provider that you must create is the OAM Identity Asserter, and it is required only if you use the oracle/wss_oam_token_service_policy policy.

For all other policies, you can use any Weblogic Authentication provider that can validate the credentials in the NameCallback and PasswordCallback callbacks, or the NameCallback alone, as appropriate. This means that you can use the WebLogic Default Authentication provider and authenticate the user against the embedded LDAP datastore if you so choose, or the Default Identity Asserter, and so forth See "Configure Authentication and Identity Assertion Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help for information on how to do this.

However, you may find that the OAM Authentication provider, described in "Using the OAM Authentication and Identity Assertion Providers" provides the most configuration options if you already use, or plan to use, Oracle Access Manager.

Using the OAM Authentication and Identity Assertion Providers

The OAM Authentication provider handles the NameCallback and PasswordCallback callbacks, or the NameCallback alone.

The OAM Identity Asserter handles the ObssoCookie token.

As a prerequisite, you must also configure Oracle Access Manager.

See "Configure Authentication and Identity Assertion Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help for information on how to configure this provider.

OAM Authentication Provider Use Case

A typical authentication use case for the OAM Authentication Provider is shown in Figure 9-6.

Figure 9-6 OAM Authentication Provider Authentication Use Case

Description of Figure 9-6 follows
Description of "Figure 9-6 OAM Authentication Provider Authentication Use Case"

When a user's Web service client tries to access a Web service protected by one of the username token policies, WebLogic Server challenges the users for credentials. The WebLogic security framework then cycles through its list of Authentication providers until the credentials are validated and an authenticated subject is generated.

In this case, the OAM Authentication provider satisfies the authentication requirement. The credentials are passed to Oracle Access Manager Access Server for validation against the configured enterprise Oracle Virtual Directory.

The process is similar for policies that require X.509 and SAML tokens. The Web service runtime environment verifies the X.509 or SAML tokens on behalf of the Web service. The X.509 or SAML login module then extracts the username from the verified token and passes it to the WebLogic Server security framework via the NameCallback.

Any configured authentication provider (or identity asserter) that handles the NameCallback can then be invoked, including the OAM Authentication provider.

In this case, the OAM Authentication provider then simply checks whether the user exists (identity assertion mode) and, if it does, the user is asserted and a subject is established.

Identity Assertion Use Case

The OAM Identity Asserter uses the ObssoCookie token to assert the identity of users who try to access a Web service protected by the oracle/wss_oam_token_service_policy policy.

A Web service that is protected by the oracle/wss_oam_token_service_policy policy must be presented with an ObssoCookie token in a SOAP header. That is, the Web service consumes the ObssoCookie token; it is not involved in how the token is generated. Specifically, the WebLogic Server security service detects the token type and invokes the OAM Identity Asserter. The OAM Identity Asserter then validates the ObssoCookie token against the Oracle Access Manager Access Server and obtains the username. The username is populated as the principal in the authenticated subject.

The Web service client needs to obtain the ObssoCookie token to send to the Web service. This is typically done via a WebGate. WebGate challenges the Web service client user for credentials (depending on the authentication scheme configured in Oracle Access Manager) and authenticates the user. The WebGate sends the ObssoCookie to the user's browser upon successful authentication.

The Web service client then sends the ObssoCookie token in the SOAP request to the Web service.

Configuring the SAML and Kerberos Login Modules

The SAML and Kerberos policies have associated login modules, as determined by the assertions that make up the policy. When you attach a SAML policy to a Web service, you must edit the login policy and make any needed changes. The Kerberos login module has settings that you can optionally configure.

(Login modules associated with other policy types do not have settings specific to the Web service policies.)

Table 9-1 lists the available login modules and which policies use them.

Table 9-1 SAML and Kerberos Login Modules and Related Policies

Login Module Service Name Description Settable Attributes and Values

saml.loginmodule

The SAML login module is a Java Authentication and Authorization Service (JAAS) login module that accepts SAML assertions to do a login. The SAML login module enables the Web services to be run using the login context of the principal created from the SAML assertion.

Issuers. Name of the issuer of the SAML token. www.oracle.com is the default.

krb5.loginmodule

Kerberos login module

principal. The name of the principal that should be used. It could be simple username such as "testuser" or a service name such as "host/testhost.eng.sun.com" . You can use principal option to set the principal when there are credentials for multiple principals in the keyTab or when you want a specific ticket cache only.

useKeyTab. True or false. Set this to true if you want the module to get the principal's key from the keytab (default value is False). If keytab is not set, then the module will locate the keytab from the Kerberos configuration file. If it is not specified in the Kerberos configuration file then it will look for the file {user.home}{file.separator}krb5.keytab.

storeKey. Set this to True to if you want the principal's key to be stored in the Subject's private credentials.

keyTab. Set this to the file name of the keytab to get principal's secret key.

doNotPrompt. Set this to true if you do not want to be prompted for the password if credentials cannot be obtained from the cache or keytab (default is false). If set to true, authentication will fail if credentials cannot be obtained from the cache or keytab.


Do the following to configure a login module:

  1. In the navigator pane, expand WebLogic Domain to show the domain for which you need to configure the keystore. Select the domain.

  2. Using Fusion Middleware Control, click Weblogic Domain, then Security, and then Security Provider Configuration.

  3. From the list of login modules, select a login module and click Edit.

  4. Configure any specific attributes or custom properties for the login module.

Configuring SAML

The SAML standard defines a common XML framework for creating, requesting, and exchanging security assertions between software entities on the Web. The SAML Token profile is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web services security. SAML also provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction, from browser to portal to networks of web services.

If you use any of the following predefined policies, you must configure SAML:

  • oracle/wss_saml_token_bearer_over_ssl_server_policy

  • oracle/wss_saml_token_bearer_over_ssl_client_policy

  • oracle/wss_saml_token_over_ssl_service_policy

  • oracle/wss_saml_token_over_ssl_client_policy

  • oracle/wss10_saml_token_service_policy

  • oracle/wss10_saml_token_client_policy

  • oracle/wss10_saml_token_with_message_protection_client_policy

  • oracle/wss10_saml_token_with_message_protection_service_policy

  • oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

  • oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy

  • oracle/wss10_saml_hok_token_with_message_protection_service_policy

  • oracle/wss10_saml_hok_token_with_message_protection_client_policy

  • oracle/wss10_saml_token_with_message_integrity_service_policy

  • oracle/wss10_saml_token_with_message_integrity_client_policy

  • oracle/wss11_saml_token_with_message_protection_service_policy

  • oracle/wss11_saml_token_with_message_protection_client_policy

How the SAML Token is Validated

The SAML login module verifies the SAML tokens on behalf of the Web service. The SAML login module then extracts the username from the verified token and (indirectly) passes it to Oracle Platform Security Services (OPSS) via the NameCallback to complete the perimeter authentication.

Which Authentication Provider is Used?

Any configured authentication provider (identity asserter) that handles the NameCallback can then be invoked, including the OAM Authentication provider.

The OAM Authentication (or other) provider then simply checks whether the user exists (identity assertion mode) and, if it does, the user is asserted and a subject is established.

How to Configure SAML Web Service Client at Design Time

Follow the steps described in this section to configure the SAML Web service client at design time. (If you attach the SAML policies to the Web service client at deploy time, you do not need to configure these properties and they are not exposed in Fusion Middleware Control.)

You can also include user roles in the assertion and change the SAML assertion issuer name, as described in subsequent sections.

Configure the Username for the SAML Assertion

For a JSE client application, configure the username as a BindingProvider property:

Map<String,Object>  reqContext = ((BindingProvider) proxy).getRequestContext()   reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")

where proxy refers to the Web service proxy used for invoking the actual Web service.

For a JEE client, if the user is already authenticated and a subject is established in the container, then the username is obtained from the subject automatically and no additional configuration is required.

For example, if user jdoe is already authenticated to the JEE application and you are making a Web service call from that JEE application, the username jdoe will be automatically propagated.

However, if the user is not authenticated, then you need to configure the username in the BindingProvider as in the JSE case.

Including User Roles in the Assertion

You can pass the user's role as an attribute statement in the SAML assertion. To do this at post-deploy time, configure the user.role.include property to "true." The default value in the policy is "false."

To configure the user's role at design time, set the user.role.include property to "true" in the BindingProvider.

Changing the SAML Assertion Issuer Name

The saml.issuer.name property must be www.oracle.com if you are using the predefined SAML policies (or assertions) on both the Web service client and Web service sides. Therefore, you can generally use the defaults and not configure any issuer.If a different client, for instance .NET/WLS, is talking to a Web service protected by a predefined SAML policy, then you need to change the issuer name property. You can pass the SAML assertion issuer name in the SAML assertion.

To do this at deploy time, set the saml.issuer.name property. The default value in the policy is www.oracle.com.

To configure the issuer at design time, set the saml.issuer.name property in the BindingProvider.

How to Configure Oracle Platform Security Services (OPSS) for SAML Policies

Follow these steps to configure OPSS for the predefined SAML policies:

  1. Configure the SAML login module, as described in "Configuring the SAML and Kerberos Login Modules".

    By default, the SAML assertion issuer name is www.oracle.com. The saml.issuer.name property must be www.oracle.com if you are using the predefined SAML policies (or assertions) on both the Web service client and Web service sides. Therefore, you can generally use the defaults and not configure any issuer.

    To use a different issuer name, click Add to add an additional issuer name as shown in Figure 9-7.

    Figure 9-7 Adding a SAML Issuer to the Login Module

    Description of Figure 9-7 follows
    Description of "Figure 9-7 Adding a SAML Issuer to the Login Module"

  2. Configure the OAM Authentication provider or other identity assertion provider in the WebLogic Server Administration Console.

  3. If you will be using policies that involve signatures related to SAML assertions (for example, SAML holder-of-key policies) where a key referenced by the assertion is used to sign the message, or sender-vouches policies where the sender's key is used to sign the message, you need to configure keys and certificates for signing and verification, as described in "Setting up the Keystore for Message Protection".

  4. If you will be using policies that require SSL, you need to configure SSL, as described in "Configuring Keystores for SSL".

Using Kerberos Tokens

Oracle Fusion Middleware 11g Release 1 (11.1.1) provides support for Kerberos tokens with the following predefined policies:

  • oracle/wss11_kerberos_token_client_policy

  • oracle/wss11_kerberos_token_service_policy

  • oracle/wss11_kerberos_token_with_message_protection_client_policy

  • oracle/wss11_kerberos_token_with_message_protection_service_policy

You may also create a policy using the following assertion templates:

  • oracle/wss11_kerberos_token_client_template

  • oracle/wss11_kerberos_token_service_template

  • oracle/wss11_kerberos_token_with_message_protection_client_template

  • oracle/wss11_kerberos_token_with_message_protection_service_template

See Appendix C, "Predefined Assertion Templates" and Appendix B, "Predefined Policies" for more information on these assertions and policies.

Configuring the KDC

Follow the steps described in this section to configure the KDC for use by the Web service client and Web service.

Initializing and Starting the KDC

Initialize KDC database. For example, on UNIX you might run the following command as root, where oracle.com is your default realm:

root# /usr/kerberos/sbin/kdb5_util -r oracle.com -s

Start the kerberos service processes. For example, on UNIX you might run the following commands as root.:

root# /usr/kerberos/sbin/krb5kdc &
root# /usr/kerberos/sbin/kadmind &

Creating Principals

Create two accounts in the KDC user registry. The first account is for the end user; that is, the Web service client principal. The second account is for the Web service principal.

One way to create these accounts is with the kadmin.local tool, which is typically provided with MIT KDC distributions. For example:

>sudo su - # become root
>cd /usr/kerberos/sbin/kadmin.local
>kadmin.local>addprinc fmwadmin -pw welcome1
>kadmin.local> addprinc SOAP/myhost.oracle.com -randkey
>kadmin.local>listprincs # to see the added principals

The Web service principal name (SOAP/myhost.oracle.com) is shown in the example as being created with a random password. The Web service principals use keytables (a file that stores the service principal name and key) to log into Keberos System. Using a random password increases security.

Configuring the Web Service Client to Use the Correct KDC

The Web service client needs to be configured to authenticate against the right KDC.

The configuration for the KDC resides at /etc/krb5.conf for UNIX hosts, and at C:\windows\krb5.ini for Windows hosts.

A sample krb5.conf is shown in Example 9-1. Note the following:

  • The file tells the kerberos runtime the realm of operation and the KDC endpoint to contact.

  • For Kerberos token policies to work, three additional properties need to be specified in the libdefaults section of this file:

    • default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

    • default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

    • permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc

  • The order of cipher suites is significant. For Keberos message protection to work, the first in the list needs to "des3-cbc-sha1". This is because Oracle WSM supports the encryption algorithm TripleDES, but not plain DES.

Example 9-1 Sample krb5.conf File

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
default_realm = oracle.com
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
 
[realms]
oracle.com =
{kdc = someadminserver.com:88  admin_server = someadminserver.com:749   
 
 
default_domain = us.oracle.com  }
[domain_realm]
us.oracle.com = oracle.com
 
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
pam =
{   debug = false    ticket_lifetime = 36000   renew_lifetime = 36000    
 
 
forwardable = true    krb4_convert = false  }

Setting the Service Principal Name in the Web Service Client

The Web service client that is enforcing Kerberos client side policies needs to know the service principal name of the service it is trying to access. You set the service principal name in "Creating Principals".

You can specify a value for service.principal.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The default (place holder) value is HOST/localhost@oracle.com.

Setting the Service Principal Name in the Web Service Client at Design Time

The Web service client that is enforcing Kerberos client side policies needs to know the service principal name of the service it is trying to access. You set the service principal name in "Creating Principals".

Use a configuration override to specify the service principal name at design time, as follows:

JAX-WS Clients: 
((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSSEC_KERBEROS_SERVICE_PRINCIPAL, SOAP/myhost.oracle.com@oracle.com);

Configuring the Web Service to Use the Right KDC

Configure the Web service to authenticate against the right KDC. The configuration for the KDC resides at /etc/krb5.conf for UNIX hosts, and at C:\windows\krb5.ini for Windows hosts.

A sample KDC configuration for a Web service client is shown in Example 9-1. This example also applies to the Web service KDC configuration.

Using the Correct Keytab File in Enterprise Manager

To use the correct keytab file, you

  • Extract and install the keytab File

  • Modify the krb5 login module

These tasks are described in the sections that follow.

Extract and Export the Keytab File

Extract the key table file, which is often referred to as the keytab, for the service principal account from the KDC and install on the machine where the web service implementation is hosted.

For example. you can use a tool such as kadmin.local to extract the keytab for the service principal name, as follows:

>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.oracle.com

Export the keytab file to the machine where the Web service is hosted. The keytab is a binary file; if you ftp it, use binary mode.

Modify the krb5 Login Module to use the Keytab File

Modify the krb5 login module as described in "Configuring the SAML and Kerberos Login Modules" to identify the location of the Web service KDC file.

For example, assume that the keytab file is installed at /scratch/myhome/krb5.keytab. Note the changes for the keytab and principal properties:

  • principal value=SOAP/myhost.oracle.com@oracle.com

  • useKeyTab value=true

  • storeKey value=true

  • keyTab value=/scratch/myhome/krb5.keytab

  • doNotPrompt value=true

Authenticating the User Corresponding to the Service Principal

The Web services runtime must be able to verify the validity of the kerberos token.

If the token is valid, Oracle Platform Security Services (OPSS) must then be able to authenticate the user corresponding to the service principal against one of the configured WebLogic Server Authentication providers. (Authentication providers are described in "Configuring an Authentication Provider in WebLogic Server".)

The user must therefore exist and be valid in the identity store used by the Authentication provider.

For example, consider a service principal such as SOAP/myhost.oracle.com@oracle.com. In this example, a user with the name SOAP/myhost.oracle.com must exist in the identity store. Note that @domain should not be part of your user entry.

Creating a Ticket Cache for the Web Service Client

Perform the following steps to create a ticket cache for the Web service client:

  1. Log in to the Kerberos system using the user principal you created for the client.

    >kinit fmwadmin welcome1
    
  2. This creates a ticket cache on the file system with ticket granting ticket. To see this:

    >klist -e
    

    Information similar to the following is displayed:

    Credentials cache: /tmp/krb5cc_36687
    Default principal: fmwadmin@oracle.com, 1 entry found.
    [1]  Service Principal:  krbtgt/oracle.com@oracle.com
         Valid starting:  Sep 28, 2007 17:20
         Expires:         Sep 29, 2007 17:20
             Encryption type: DES3 CBC mode with SHA1-KD
    

    Make sure the encryption type reflects what is shown above.

  3. Run the web service client.

Alternatively , you can run the Web service client without first logging into the Kerberos system. You are prompted for the Kerberos user name and password. Note that in this case a ticket cache is not created on the file system; it is maintained in memory.

Two Ways to Attach Policy Files to Web Service Clients

There are two ways to attach policies to Web service clients and Web services: at the client and service design time, and post deployment.

Post-deployment, you attach security and management policies to SOA composites, ADF, and WebCenter applications using the Oracle Enterprise Manager Fusion Middleware Control. This method provides the most power and flexibility because it moves Web service security to the control of the security administrator.

At design time, Oracle JDeveloper automates ADF and SOA client policy attachment. Or, you can attach Oracle WSM security and management policies to applications programmatically. You typically do this using your favorite IDE, such as Oracle JDeveloper.

Either way, the client-side policy must be the equivalent of the one associated with the Web service. If the two files are different, and there is a conflict in the assertions contained in the files, then the invoke of the Web service operation returns an error.

For example, if the oracle/wss_http_token_over_ssl_service_policy policy requires mutual authentication, the client policy must also be set for mutual authentication.

For the predefined policies, both client and Web service are included. If you create a new policy, generating the policy as described in "Creating Web Service Policies" increases the likelihood that the client policy will work with the service policy.

Client Programmatic Configuration Overrides

"Attaching Client Policies Permitting Overrides" describes the policy configuration override feature that allows you to specify certain Web service client configuration information when you attach a policy. However, you can also override this configuration information programmatically at design time. This section describes client programmatic overrides.

Table 9-2 shows the properties you can set via programmatic configuration overrides for a given policy. Example 9-2 shows an example of setting these properties from a program.

Table 9-2 Properties Set Via Programmatic Configuration Overrides

Property List Description Applies to These Policies

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_CSF_KEY

Gets the username and password corresponding to the csf-key specified in the credential store if the credential store is available to the client.

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss_username_token_client_policy

oracle/wss_username_token_over_ssl_client_policy

oracle/wss_username_token_with_digestpassword_client_policy

oracle/wss10_username_id_propagation_with_msg_protection_client_policy

oracle/wss_http_token_client_policy

oracle/wss_http_token_over_ssl_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION

This property sets the location of the keystore file. If provided, this value will override any statically configured value. Type: java.lang.String

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_TYPE

This property sets the type of keystore file. If provided, this value will override any statically configured value. Type: java.lang.String Default is JKS.

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_PASSWORD

This property sets the password of the keystore file. If provided, this value will override any statically configured value. Type: java.lang.String

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_SIG_KEY_ALIAS

This property sets the alias of the key within the keystore that will be used for digital signatures. If provided, this value will override any statically configured value. Type: java.lang.String

For WSS11 policies, this property is used only in the case of mutual authentication.

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_SIG_KEY_PASSWORD

This property sets the password for the alias of the key within the keystore that will be used for digital signatures. If provided, this value will override any statically configured value. Type: java.lang.String

For WSS11 policies, this property is used only in the case of mutual authentication.

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_ENC_KEY_ALIAS

This property sets the alias of the key within the keystore that will be used to decrypt the response from the service. If provided, this value will override any statically configured value. Type: java.lang.String

Not used in WSS11 policies.

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_ENC_KEY_PASSWORD

This property sets the password for the key within the keystore that will be used for decryption. If provided, this value will override any statically configured value. Type: java.lang.String

Not used in WSS11 policies.

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIAS

This property sets the alias for the recipient's public key that is used to encrypt type outbound message. If provided this value will override any static configuration value. Type: java.lang.String

oracle/wss10_message_protection_client_policy

oracle/wss10_saml_hok_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_integrity_client_policy

oracle/wss10_saml_token_with_message_protection_client_policy

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_username_token_with_message_protection_client_policy

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

oracle/wss10_x509_token_with_message_protection_client_policy

oracle/wss11_kerberos_token_with_message_protection_client_policy

oracle/wss11_message_protection_client_policy

oracle/wss11_saml_token_with_message_protection_client_policy

oracle/wss11_username_token_with_message_protection_client_policy

oracle/wss11_x509_token_with_message_protection_client_policy

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_SUBJECT_PRECEDENCE

In case of SAML client policies, set this property to false if there is a need to use a client-specified username rather than subject.

Applies to all of the SAML client policies listed in "Configuring SAML".

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_SAML_ISSUER_NAME

This property sets the SAML issuer name when trying access a service that is protected using SAML mechanism. If provided this value will override any static configuration value. Type: java.lang.String

Applies to all of the SAML client policies listed in "Configuring SAML".

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_INCLUDE_USER_ROLES

This property sets the user roles in a SAML assertion.

Applies to all of the SAML client policies listed in "Configuring SAML".

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_SAML_ASSERTION_FILE_NAME

For SAML HOK policies, this file contains the assertion

Applies to all of the SAML client policies listed in "Configuring SAML".

oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KERBEROS_SERVICE_PRINCIPAL

This property sets the service principal name when trying access a service that is protected using the Kerberos mechanism. If provided this value will override any static configuration value. Type: java.lang.String

oracle/wss11_kerberos_token_with_message_protection_client_policy


Configuration Override Example

Example 9-2 shows an example of a Web service client overriding the keystore and username/password.

If you need to clear an overridden configuration property, set it to an empty string.

Before you clear it, remember that other policies could be using the same property. The properties are client-specific and there could be multiple policies that are attached to the same client that use the same property.

Example 9-2 Overriding the Keystore and Username/Password

package example;
import oracle.wsm.security.utils.SecurityConstants;
public class MyClientJaxWs {
    public static void main(String[] args) {
        try {
            URL serviceWsdl = new URL("http://localhost/myApp/myPort?WSDL");
            QName serviceName = new QName("MyNamespace", "MyService");
            Service service = Service.create(serviceWsdl, serviceName);
            MyInterface proxy = service.getPort(MyInterface.class);
            RequestContext context = ((BindingProvider)proxy).getRequestContext();
            context.put(oracle.webservices.ClientConstants.CLIENT_CONFIG, new File( "c:/dat/client-pdd.xml" ) );
            context.put(BindingProvider.USERNAME_PROPERTY, getCurrentUsername() );
            context.put(BindingProvider.PASSWORD_PROPERTY, getCurrentPassword() );
            context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION, "c:/mykeystore.jks");
            context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_PASSWORD, "keystorepassword" );
            context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_TYPE, "JKS" );
            context.put(SecurityConstants.ClientConstants.WSS_SIG_KEY_ALIAS, "your signature alias" );
            context.put(SecurityConstants.ClientConstants.WSS_SIG_KEY_PASSWORD, "your signature password" );
            context.put(SecurityConstants.ClientConstants.WSS_ENC_KEY_ALIAS, "your encryption alias" );
            context.put(SecurityConstants.ClientConstants.WSS_ENC_KEY_PASSWORD, "your encryption password" );
            System.out.println(proxy.myOperation("MyInput"));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

In Example 9-2, the contents of c:/dat/client-pdd.xml referenced might be as follows:

! -- The contents of c:/dat/client-pdd.xml file mentioned above -- >
<oracle-webservice-clients>
  <webservice-client>
    <port-info>
      <policy-references>
        <policy-reference uri="management/Log_Msg_Policy" category="management"/>
        <policy-reference uri="oracle/wss10_username_token_with_message_protection_client_policy" category="security"/>
      </policy-references>
    </port-info>
  </webservice-client>
</oracle-webservice-clients>

Configuring Local Optimization

Oracle WSM supports a SOA local optimization feature for composite-to-composite invocations in which the reference of one composite specifies a web service binding to a second composite. Both composites must be running in the same container.

The optimization control is available when you create or edit a policy, as shown in Figure 9-8, and it provides for the following:

  • HTTP is not called

  • SOAP/Normalized Message conversion is not needed

Figure 9-8 Local Optimization Control When Creating a Policy

Description of Figure 9-8 follows
Description of "Figure 9-8 Local Optimization Control When Creating a Policy"

If there is a policy attached to the Web service, the policy may not be invoked if this optimization is used. Therefore, for each policy you need to decide whether you want to use the local optimization.

There are three possible settings for the Local Optimization control: On, Off, and Check Identity:

  • On -- Optimization is turned on.

  • Off -- Optimization is turned off. The request goes through the usual WS/SOAP/HTTP process.

  • Check Identity -- Optimize only if a JAAS subject already exists in the current thread, indicating that authentication has already succeeded. Otherwise, go through the usual WS/SOAP/HTTP process.

Table 9-3 shows the predefined policies, and describes how each policy implements the local optimization feature.

Table 9-3 Default Optimization Setting of Predefined Policies

Policy Name Default Optimization Setting

oracle/wsaddr_policy

On

oracle/binding_authorization_denyall_policy

Always Off

oracle/binding_authorization_permitall_policy

Always Off

oracle/binding_permission_authorization_policy

Off

oracle/component_authorization_denyall_policy

Always Off. (Does not apply to bindings.)

oracle/component_authorization_permitall_policy

Always Off. (Does not apply to bindings.)

oracle/component_permission_authorization_policy

Off

oracle/log_policy

On

oracle/wsmtom_policy

On

oracle/wss_oam_token_client_policy

Always Off

oracle/wss_oam_token_service_policy

Always Off

oracle/wss_http_token_client_policy

Check Identity

oracle/wss_http_token_service_policy

Check Identity

oracle/wss_http_token_over_ssl_client_policy

Check Identity

oracle/wss_http_token_over_ssl_service_policy

Check Identity

oracle/wss11_kerberos_token_client_policy

Check Identity

oracle/wss11_kerberos_token_service_policy

Check Identity

oracle/wss_username_token_client_policy

Check Identity

oracle/wss_username_token_service_policy

Check Identity

oracle/wss_username_token_over_ssl_client_policy

Check Identity

oracle/wss_username_token_over_ssl_service_policy

Check Identity

oracle/wss10_message_protection_client_policy

On

oracle/wss10_message_protection_service_policy

On

oracle/wss10_username_token_with_message_protection_client_policy

Check Identity

oracle/wss10_username_token_with_message_protection_service_policy

Check Identity

oracle/wss10_x509_token_with_message_protection_client_policy

Check Identity

oracle/wss10_x509_token_with_message_protection_service_policy

Check Identity

oracle/wss10_saml_token_with_message_protection_client_policy

Check Identity

oracle/wss10_saml_token_with_message_protection_service_policy

Check Identity

oracle/wss10_saml_token_client_policy

Check Identity

oracle/wss10_saml_token_service_policy

Check Identity

oracle/wss10_username_id_propagation_with_msg_protection_client_policy

Check Identity

oracle/wss10_username_id_propagation_with_msg_protection_service_policy

Check Identity

oracle/wss11_message_protection_client_policy

On

oracle/wss11_message_protection_service_policy

On

oracle/wss11_username_token_with_message_protection_client_policy

Check Identity

oracle/wss11_username_token_with_message_protection_service_policy

Check Identity

oracle/wss11_x509_token_with_message_protection_client_policy

Check Identity

oracle/wss11_x509_token_with_message_protection_service_policy

Check Identity

oracle/wsrm10_policy

On

oracle/wsrm11_policy

On


Authentication-Only Policies and Configuration Steps

Table B-1 in Appendix B, "Predefined Policies" summarizes the security policies that enforce authentication only, and indicates whether the token is inserted at the transport layer or SOAP header.

This section lists the authentication-only predefined policies, indicates the type of Web service to which they apply, and provides a link to the configuration steps you must perform to use them.

oracle/wss_http_token_client_policy

The oracle/wss_http_token_client_policy policy includes credentials in the HTTP header for outbound client requests. It is the analogous client policy to the oracle/wss_http_token_service_policy service endpoint policy.

This policy contains the following policy assertion: oracle/wss_http_token_client_template. See "oracle/wss_http_token_client_template" for more information about the assertion.

Settings You Can Change

See Table C-2.

Properties You Can Configure

See Table C-3.

How to Set Up the Web Service Client

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

If you do not set the Require Mutual Authentication control, SSL is not involved. If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

How to Set Up the Web Service Client at Design Time

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

The client must pass the credentials in the HTTP header.

If you do not set the Require Mutual Authentication control, SSL is not involved. If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

oracle/wss_http_token_service_policy

The wss_http_token_service_policy uses the credentials in the HTTP header to authenticate users.

This policy contains the following policy assertion: oracle/wss_http_token_service_template. See "oracle/wss_http_token_service_template" for more information about the assertion.

Settings You Can Change

See Table C-2.

Properties You Can Configure

See Table C-4.

How to Set Up WebLogic Server

The Web service must authenticate the supplied username and password credentials against the configured authentication source.

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

For mutual SSL authentication, you must configure WebLogic Server. See "Configuring SSL on WebLogic Server (Two-Way)".

oracle/wss_oam_token_client_policy

The oracle/wss_oam_token_client_policy policy inserts Oracle Access Manager credentials into the WS-Security header as part of the binary security token. It is the analogous client policy to the oracle/wss_oam_token_service_policy service endpoint policy.

This policy contains the following policy assertion: oracle/wss_oam_token _client_template. See "oracle/wss_oam_token_client_template" for more information about the assertion.

Settings You Can Change

See Table C-5.

Properties You Can Configure

See Table C-6.

How to Set Up the Web Service Client

This policy does not require any client configuration from Fusion Middleware Control.

How to Set Up the Web Service Client at Design Time

As described in "Configuring an Authentication Provider in WebLogic Server", a web server is used as a reverse proxy for all the requests to the Web service. WebGate on the reverse proxy Web server intercepts all the requests and challenges the Web service client user for credentials (depending on the authentication scheme configured in OAM) and authenticates a user. The recommended authentication scheme is FORM login.

Therefore, the Web service client needs to provide username and password credentials when challenged.

oracle/wss_oam_token_service_policy

This policy uses the credentials in the WS-Security header's binary security token to authenticate users against the Oracle Access Manager identity store. This policy can be enforced on any SOAP-based endpoint.

This policy contains the following policy assertion: oracle/wss_oam_token_service_template. See "oracle/wss_oam_token_service_template" for more information about the assertion.

Settings You Can Change

See Table C-5.

Properties You Can Configure

See Table C-6.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add a provider of type OAMIdentityAsserter to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The OAM Identity Asserter validates the ObssoCookie token it is given.

See "Configure Authentication and Identity Assertion Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help for detailed information on configuring this provider for identity assertion.

oracle/wss_username_token_client_policy

This policy includes credentials in the WS-Security UsernameToken header for all outbound SOAP request messages. A plain text mechanism is supported, in addition to a password not being required. It is the analogous client policy to the oracle/wss_username_token_service_policy service endpoint policy.

This policy contains the following policy assertion: oracle/wss_username_token_client_template. See "oracle/wss_username_token_client_template" for more information about the assertion.

Settings You Can Change

See Table C-7.

Properties You Can Configure

See Table C-8.

How to Set Up the Web Service Client

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

If you specify a password type of None on the Settings page, you do not need to include a password in the key.

How to Set Up the Web Service Client At Design Time

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

The client must include a WS-Security UsernameToken element (<wsse:UsernameToken/>) in the SOAP request message. The client provides a username and password for authentication.

oracle/wss_username_token_service_policy

This policy uses the credentials in the UsernameToken WS-Security SOAP header to authenticate users. The plain text mechanism is supported.

This policy contains the following policy assertion: oracle/wss_username_token_service_template. See "oracle/wss_username_token_service_template" for more information about the assertion.

Settings You Can Change

See Table C-7.

Properties You Can Configure

See Table C-9.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

oracle/wss10_saml_token_client_policy

This policy includes SAML tokens in outbound SOAP request messages.

This policy contains the following policy assertion: oracle/wss10_saml_token_client_template. See "oracle/wss10_saml_token_client_template" for more information about the assertion.

Settings You Can Change

See Table C-10.

Properties You Can Configure

See Table C-11.

How to Set Up the Web Service Client

See "Configuring SAML".

You can optionally specify a value for saml.issuer.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The saml.issuer.name property defaults to a value of www.oracle.com. See "Changing the SAML Assertion Issuer Name" for additional considerations.

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Include a WS-Security Header Element (<saml:Assertion>) that inserts a SAML token in the outbound SOAP message. The confirmation type is always sender-vouches.

oracle/wss10_saml_token_service_policy

This policy authenticates users using credentials provided in SAML tokens in the WS-Security SOAP header.

This policy contains the following policy assertion: oracle/wss10_saml_token_service_template. See "oracle/wss10_saml_token_service_template" for more information about the assertion.

Settings You Can Change

See Table C-10.

Properties You Can Configure

See Table C-12.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up Oracle Platform Security Services (OPPS)

See "Configuring SAML".

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

oracle/wss11_kerberos_token_client_policy

This policy includes a Kerberos token in the WS-Security header in accordance with the WS-Security Kerberos Token Profile v1.1 standard.

Service principal names (SPN) are a key component in Kerberos authentication. SPNs are unique identifiers for services running on servers. Every service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, clients have no way of locating that service and Kerberos authentication is not possible.

This policy contains the following policy assertion: oracle/wss11_kerberos_token_client_template. See "oracle/wss11_kerberos_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-44.

Properties You Can Configure

See Table C-45.

How to Set Up the Web Service Client

See "Using Kerberos Tokens".

The Web service client that is enforcing Kerberos client side policies needs to know the service principal name of the service it is trying to access. You can specify a value for service.principal.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The default value (place holder) is HOST/localhost@oracle.com.

How to Set Up the Web Service Client at Design Time

See "Using Kerberos Tokens".

You must set the service principal name. The service principal name specifies the name of the service principal for which the client requests a ticket from the KDC.

If the Kerberos authentication is successful, then send the obtained Kerberos ticket and authenticator to the Web service enclosed in a BinarySecurityToken element in the SOAP Security header.

oracle/wss11_kerberos_token_service_policy

This policy is enforced in accordance with the WS-Security Kerberos Token Profile v1.1 standard.

Service principal names (SPN) are a key component in Kerberos authentication. SPNs are unique identifiers for services running on servers. Every service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, clients have no way of locating that service and Kerberos authentication is not possible.

This policy contains the following policy assertion: oracle/wss11_kerberos_token_service_template. See "oracle/wss11_kerberos_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-44.

Properties You Can Configure

See Table C-46.

Configure the Login Module

Configure the krb5.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Configure WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

Message Protection-Only Policies and Configuration Steps

See "Protecting Messages" for a description of how the predefined policies implement message protection.

Table B-2 summarizes the policies that enforce only message protection, and indicates whether the policy is enforced at the transport layer or SOAP header.

Message protection-only policies do not authenticate or authorize the requester.

There may be either one or two Security policies attached to a policy subject. A Security policy can contain an assertion that belongs to the authentication or message protection (as in this case) subtype categories, or a single assertion that belongs to both subtype categories. You can then use an assertion that belongs to the authorization subtype to authorize the requester.

oracle/wss10_message_protection_client_policy

This policy provides message protection (integrity and confidentiality) for outbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_message_protection_client_template. See "oracle/wss10_message_protection_client_policy" for more information about the assertion.

Settings You Can Change

See Table C-17.

Properties You Can Configure

See Table C-18.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

How to Set Up the Web Service Client at Design Time

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-3 WS-Security 1.0 Message Integrity of SOAP Message

<dsig:Signature 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="#Timestamp-...">
     <dsig:Transforms>
       <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
     </dsig:Transforms>
     <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <dsig:DigestValue>...</dsig:DigestValue>
  </dsig:Reference>
  <dsig:Reference URI="#Body-...">
     <dsig:Transforms>
         <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
     </dsig:Transforms>
     <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <dsig:DigestValue>...</dsig:DigestValue>
  </dsig:Reference>
  <dsig:Reference URI="#KeyInfo-...">
   <dsig:Transforms>
     <dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
       <TransformationParameters xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
       <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns="http://www.w3.org/2000/09/xmldsig#"/>
       </TransformationParameters>
     </dsig:Transform>
   </dsig:Transforms>
   <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <dsig:DigestValue>...</dsig:DigestValue>
  </dsig:Reference>
 </dsig:SignedInfo>
 <dsig:SignatureValue>....</dsig:SignatureValue>
 <dsig:KeyInfo Id="KeyInfo-...">
     <wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
...</wsse:KeyIdentifier>
     </wsse:SecurityTokenReference>
 </dsig:KeyInfo>
</dsig:Signature>

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

Example 9-4 WS-Security 1.0 Message Confidentiality of SOAP Message

<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Body-JA9fsCRnqbFJ0ocBAMKb7g22">
 <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content" Id="...">
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
  <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
  </xenc:CipherData>
 </xenc:EncryptedData>
</env:Body>

oracle/wss10_message_protection_service_policy

This policy enforces message protection (integrity and confidentiality) for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

The messages are protected using WS-Security's Basic 128 suite of asymmetric key technologies, specifically RSA key mechanism for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption. This policy does not authenticate or authorize the requester.

This policy contains the following policy assertion: oracle/wss10_message_protection_service_template. See "oracle/wss10_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-17.

Properties You Can Configure

See Table C-19.

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss11_message_protection_client_policy

This policy provides message integrity and confidentiality for outbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_message_protection_client_template. See "oracle/wss11_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-20.

Properties You Can Configure

See Table C-21.

How to Configure the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

How to Configure the Web Service Client at Design Time

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

This policy uses symmetric key technology, which is an encryption method that uses the same shared key to encrypt and decrypt data. The symmetric key is used to sign the message.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-5 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.1 standards. In this example, the body element is encrypted.

Example 9-5 WS-Security 1.1 Message Confidentiality of SOAP Message

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EK-...">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" />
</xenc:EncryptionMethod>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">...</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue> 
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#_..." /> 
</xenc:ReferenceList>
</xenc:EncryptedKey>
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Body-...">
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content" Id="...">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
    <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:Reference URI="#EK-..." ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" />
      </wsse:SecurityTokenReference>
    </dsig:KeyInfo>
    <xenc:CipherData>
        <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</env:Body>

oracle/wss11_message_protection_service_policy

This policy enforces message integrity and confidentiality for inbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_message_protection_service_template. See "oracle/wss11_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-20.

Properties You Can Configure

See Table C-22.

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

Message Protection and Authentication Policies and Configuration Steps

Table B-3 summarizes the policies that enforce both message protection and authentication, and indicates whether the policy is enforced at the transport layer or SOAP header. These polices are described in the sections that follow.

See "Protecting Messages" for a description of how the predefined policies implement message protection.

oracle/wss_http_token_over_ssl_client_policy

This policy includes credentials in the HTTP header for outbound client requests.

This policy also verifies that the transport protocol is HTTPS. Requests over a non-HTTPS transport protocol are refused. This policy can be applied to any HTTP-based endpoint.

Note:

Currently only HTTP basic authentication is supported.

This policy contains the following policy assertion: oracle/wss_http_token_over_ssl_client_template. See "oracle/wss_http_token_over_ssl_client_template" for more information about the assertion.

Setting You Can Change

See Table C-24.

Properties You Can Configure

See Table C-25.

How to Set Up the Web Services Client

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

If you do not set the Require Mutual Authentication control, one-way SSL is involved. See "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

How to Set Up the Web Service Client at Design Time

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

The client must pass the credentials in the HTTP header.

If you do not set the Require Mutual Authentication control, one-way SSL is involved. See "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

oracle/wss_http_token_over_ssl_service_policy

This policy extracts the credentials in the HTTP header and authenticates users.

This policy verifies that the transport protocol is HTTPS. Requests over a non-HTTPS transport protocol are refused. This policy can be applied to any HTTP-based endpoint.

Note:

Currently only HTTP basic authentication is supported.

This policy contains the following policy assertion: oracle/wss_http_token_over_ssl_service_template. See "oracle/wss_http_token_over_ssl_service_template" for more information about the assertion.

Settings You Can Change

See Table C-24.

Properties You Can Configure

See Table C-26.

How to Set Up WebLogic Server

Configure SSL, as described in "Configuring SSL on WebLogic Server (One-Way)", or as in "Configuring SSL on WebLogic Server (Two-Way)" if Allow Mutual Authentication is checked.

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

oracle/wss_saml_token_bearer_over_ssl_client_policy

This policy includes SAML tokens in outbound SOAP request messages. The SAML token with confirmation method Bearer is created automatically.

This policy contains the following policy assertion: oracle/wss_saml_token_bearer_over_ssl_client_template. See "oracle/wss_saml_token_bearer_over_ssl_client_template" for more information about the assertion.

Settings You Can Change

See Table C-27

Properties You Can Configure

None.

How to Set Up the Web Service Client

See "How to Configure SAML Web Service Client at Design Time".

If you do not set the Require Mutual Authentication control, one-way SSL is involved, as described in "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

If you do not set the Require Mutual Authentication control, one-way SSL is involved, as described in "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

oracle/wss_saml_token_bearer_over_ssl_service_policy

This policy authenticates users using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header.

This policy contains the following policy assertion: oracle/wss_saml_token_bearer_over_ssl_service_template. See "oracle/wss_saml_token_bearer_over_ssl_service_template" for more information about the assertion.

Settings You Can Change

See Table C-27.

Properties You Can Configure

None.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

To configure SSL, see "Configuring SSL on WebLogic Server (One-Way)", or "Configuring SSL on WebLogic Server (Two-Way)" if Require Mutual Authentication is checked.

oracle/wss_saml_token_over_ssl_client_policy

This policy enables the authentication of credentials provided via a SAML token within WS-Security SOAP header.

This policy contains the following policy assertion: oracle/wss_saml_token_over_ssl_client_template. See "oracle/wss_saml_token_over_ssl_client_template" for more information about the assertion.

Settings You Can Change

See Table C-28.

Properties You Can Configure

None.

How to Set Up the Web Service Client

See "How to Configure SAML Web Service Client at Design Time".

If you do not set the Require Mutual Authentication control, one-way SSL is involved, as described in "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

If you do not set the Require Mutual Authentication control, one-way SSL is involved, as described in "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

oracle/wss_saml_token_over_ssl_service_policy

This policy enforces the authentication of credentials provided via a SAML token within WS-Security SOAP header.

This policy contains the following policy assertion: oracle/wss_saml_token_over_ssl_service_template. See "oracle/wss_saml_token_over_ssl_service_template" for more information about the assertion.

Settings You Can Change

See Table C-28

Properties You Can Configure

None.

Configure the Login Module.

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

To configure SSL, see "Configuring SSL on WebLogic Server (One-Way)", or "Configuring SSL on WebLogic Server (Two-Way)" if Require Mutual Authentication is checked.

oracle/wss_username_token_over_ssl_client_policy

This policy includes credentials in the WS-Security UsernameToken header in outbound SOAP request messages. The plain text mechanism is supported. The policy also uses SSL for achieving transport layer security.

This policy contains the following policy assertion: oracle/wss_username_token_over_ssl_client_template. See "oracle/wss_username_token_over_ssl_client_template" for more information about the assertion.

Settings You Can Change

See Table C-29.

Properties You Can Configure

See Table C-30.

How to Set Up the Web Service Client

If you do not set the Require Mutual Authentication control, one-way SSL is involved, as described in "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

If you specify a password type of None on the Settings page, you do not need to include a password in the key.

How to Set Up the Web Service Client at Design Time

The client must include a WS-Security UsernameToken element (<wsse:UsernameToken/>) in the SOAP request message. The client provides a username and password for authentication.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

If you do not set the Require Mutual Authentication control, one-way SSL is involved. See "Configuring SSL for a Web Service Client".

If you do set the Require Mutual Authentication control, the client must supply credentials, and expect credentials back from the Web service. See "Configuring Two-Way SSL for a Web Service Client".

oracle/wss_username_token_over_ssl_service_policy

This policy uses the credentials in the UsernameToken WS-Security SOAP header to authenticate users. The plain text mechanism is supported.

This policy contains the following policy assertion: oracle/wss_username_token_over_ssl_service_template. See "oracle/wss_username_token_over_ssl_service_template" for more information about the assertion.

Settings You Can Change

See Table C-29.

Properties You Can Configure

See Table C-31.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The username and password must exist and be valid.

To configure SSL, see "Configuring SSL on WebLogic Server (One-Way)", or "Configuring SSL on WebLogic Server (Two-Way)" if Require Mutual Authentication is checked.

oracle/wss10_saml_hok_token_with_message_protection_client_policy

This policy provides message-level protection and SAML holder of key based authentication for outbound SOAP messages in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_hok_with_message_integrity_client_template. See "oracle/wss10_saml_hok_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-32.

Properties You Can Configure

See Table C-33.

How to Set Up the Web Service Client

See "How to Configure SAML Web Service Client at Design Time".

Override the saml.assertion.filename property to point to the file that has the holder-of-key assertion.

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

Override the saml.assertion.filename property to point to the file that has the holder-of-key assertion. See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_saml_hok_token_with_message_protection_service_policy

This policy enforces message-level protection and SAML holder of key based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_hok_with_message_integrity_service_template. See "oracle/wss10_saml_hok_with_message_protection_service_template" for more information about the assertion.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or another provider.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate of the SAML authority in the keystore.

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_saml_token_with_message_integrity_client_policy

This policy provides message-level integrity and SAML-based authentication for outbound SOAP messages in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_integrity_client_template. See "oracle/wss10_saml_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-36.

How to Set Up the Web Service Client

See "Configuring SAML".

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can optionally specify a value for saml.issuer.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The saml.issuer.name property defaults to a value of www.oracle.com. See "Changing the SAML Assertion Issuer Name" for additional considerations.

You can specify a value for user.roles.include on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

Include a WS-Security Header Element (<saml:Assertion>) that inserts a SAML token in the outbound SOAP message. The confirmation type is always sender-vouches.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_saml_token_with_message_integrity_service_policy

This policy enforces message-level integrity protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_integrity_service_template. See "oracle/wss10_saml_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-37.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

oracle/wss10_saml_token_with_message_protection_client_policy

This policy provides message-level protection and SAML-based authentication for outbound SOAP messages in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_protection_client_template. See "oracle/wss10_saml_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-36.

How to Set Up the Web Service Client

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

You can optionally specify a value for saml.issuer.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The saml.issuer.name property defaults to a value of www.oracle.com. See "Changing the SAML Assertion Issuer Name" for additional considerations.

You can specify a value for user.roles.include on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_saml_token_with_message_protection_service_policy

This policy enforces message-level protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_protection_service_template. See "oracle/wss10_saml_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-37.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy

This policy provides message-level protection and SAML-based authentication for outbound SOAP messages in accordance with the WS-Security 1.0 standard.

This policy uses the Subject Key Identifier (ski) reference mechanism for the encryption key in the request, and for both the signature and encryption keys in the response.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_protection_client_template. See "oracle/wss10_saml_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-36.

How to Set Up the Web Service Client

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

You can optionally specify a value for saml.issuer.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The saml.issuer.name property defaults to a value of www.oracle.com. See "Changing the SAML Assertion Issuer Name" for additional considerations.

You can specify a value for user.roles.include on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy

This policy enforces message-level protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy uses the Subject Key Identifier (ski) reference mechanism for the encryption key in the request, and for both the signature and encryption keys in the response.

This policy contains the following policy assertion: oracle/wss10_saml_token_with_message_protection_service_template. See "oracle/wss10_saml_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-35.

Properties You Can Configure

See Table C-37.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore. When using the ski reference mechanism, use OpenSSL or another such utility to create the certificate.

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_username_id_propagation_with_msg_protection_client_policy

This policy provides message-level protection (that is, integrity and confidentiality) and identity propagation for outbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_username_id_propagation_with_msg_protection_client_template. See "oracle/wss10_username_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-38.

Properties You Can Configure

See Table C-39.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

How to Set Up the Web Service Client at Design Time

The client must include a WS-Security UsernameToken element (<wsse:UsernameToken/>) in the SOAP request message. The client provides a username and password for authentication.

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

Configure the policy assertion for message signing, message encryption, or both.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_username_id_propagation_with_msg_protection_service_policy

This policy enforces message level protection (that is, integrity and confidentiality) and identity propagation for inbound SOAP requests using mechanisms described in WS-Security 1.0.

This policy contains the following policy assertion: oracle/wss10_username_id_propagation_with_msg_protection_service_template. See "oracle/wss10_username_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-39.

Properties You Can Configure

See Table C-41.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules" for more information.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

How to Set Up Oracle Platform Security Services (OPSS

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_username_token_with_message_protection_client_policy

This policy provides message-level protection (message integrity and confidentiality) and authentication for outbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_username_token_with_message_protection_client_template. See "oracle/wss10_username_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-38.

Properties You Can Configure

See Table C-39.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

How to Set Up the Web Service Client at Design Time

Configure the policy assertion for message signing, message encryption, or both.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_username_token_with_message_protection_service_policy

This policy enforces message-level protection (message integrity and confidentiality) and authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_username_token_with_message_protection_service_template. See "oracle/wss10_username_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-38.

Properties You Can Configure

See Table C-40.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy

This policy provides message-level protection (message integrity and confidentiality) and authentication for outbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy uses the Subject Key Identifier (ski) reference mechanism for the encryption key in the request, and for both the signature and encryption keys in the response.

This policy contains the following policy assertion: oracle/wss10_username_token_with_message_protection_client_template. See "oracle/wss10_username_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-38.

Properties You Can Configure

See Table C-39.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

You can specify a value for csf-key on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The value signifies a key that maps to a username/password. See "Configuring the Credential Store Provider" for information on how to add the key to the credential store.

How to Set Up the Web Service Client at Design Time

Configure the policy assertion for message signing, message encryption, or both.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy

This policy enforces message-level protection (message integrity and confidentiality) and authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy uses the Subject Key Identifier (ski) reference mechanism for the encryption key in the request, and for both the signature and encryption keys in the response.

This policy contains the following policy assertion: oracle/wss10_username_token_with_message_protection_service_template. See "oracle/wss10_username_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-38.

Properties You Can Configure

See Table C-40.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore. When using the ski reference mechanism, use OpenSSL or another such utility to create the certificate.

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

oracle/wss10_x509_token_with_message_protection_client_policy

This policy provides message-level protection and certificate credential population for outbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_x509_token_with_message_protection_client_template. See "oracle/wss10_x509_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-41.

Properties You Can Configure

See Table C-42.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

How to Set Up the Web Service Client at Design Time

The Web service client needs to provide valid X.509 authentication credentials in the SOAP message through the WS-Security binary security token.

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-3 shows the typical structure of a signature included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element of the SOAP message is signed.

Example 9-4 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.0 standards. In this example, the body element is encrypted.

oracle/wss10_x509_token_with_message_protection_service_policy

This policy enforces message-level protection and certificate-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss10_x509_token_with_message_protection_service_template. See "oracle/wss10_x509_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-41.

Attributes You Can Configure

See Table C-43.

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

How to Set Up WebLogic Server

You need to configure the OAM Authentication provider or another Authentication provider, as described in "Configuring an Authentication Provider in WebLogic Server", and make sure that you provide the X.509 callback information for this provider.

oracle/wss11_kerberos_token_with_message_protection_client_policy

This policy includes a Kerberos token in the WS-Security header, and uses Kerberos keys to guarantee message integrity and confidentiality, in accordance with the WS-Security Kerberos Token Profile v1.1 standard.

This policy contains the following policy assertion: oracle/wss11_kerberos_token_with_message_protection_client_template. See "oracle/wss11_kerberos_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-44.

Properties You Can Configure

See Table C-45.

How to Set up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

Also see "Using Kerberos Tokens".

How to Set Up the Web Service Client at Design Time

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time".

Also see "Using Kerberos Tokens".

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-5 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.1 standards. In this example, the body element is encrypted.

oracle/wss11_kerberos_token_with_message_protection_service_policy

This policy is enforced in accordance with the WS-Security Kerberos Token Profile v1.1 standard.

This policy contains the following policy assertion: oracle/wss11_kerberos_token_with_message_protection_service_template. See "oracle/wss11_kerberos_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-44.

Properties You Can Configure

See Table C-46.

Configure the Login Module

Configure the krb5.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules".

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

Configure Kerberos, as described in "Using Kerberos Tokens".

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

oracle/wss11_saml_token_with_message_protection_client_policy

This policy enables message level protection and SAML token population for outbound SOAP requests using mechanisms described in WS-Security 1.1.

This policy contains the following policy assertion: oracle/wss11_saml_token_with_message_protection_client_template. See "oracle/wss11_saml_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-47.

Properties You Can Configure

See Table C-48.

How to Set Up the Web Service Client

See "How to Configure SAML Web Service Client at Design Time".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

You can specify a value for keystore.recipient.alias on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

The keystore recipient alias specifies the alias used to look up the public key in the keystore when retrieving a key for encryption of outbound SOAP messages.

You can optionally specify a value for saml.issuer.name on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy. The saml.issuer.name property defaults to a value of www.oracle.com. See "Changing the SAML Assertion Issuer Name" for additional considerations.

You can specify a value for user.roles.include on the Configurations page, or override it on a per-client basis using the Security Configuration Details control when you attach the policy.

How to Set Up the Web Service Client at Design Time

See "How to Configure SAML Web Service Client at Design Time".

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-5 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.1 standards. In this example, the body element is encrypted.

oracle/wss11_saml_token_with_message_protection_service_policy

This policy enforces message-level integrity protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard.

This policy contains the following policy assertion: oracle/wss11_saml_token_with_message_protection_service_template. See "oracle/wss11_saml_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-47.

Properties You Can Configure

See Table C-48.

Configure the Login Module

Configure the saml.loginmodule login module. See "Configuring the SAML and Kerberos Login Modules".

How to Set Up Oracle Platform Security Services (OPSS)

See "Configuring SAML".

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

The SAML login module extracts the username from the verified token and passes it (via the NameCallback) to the OAM Authentication provider or other provider.

oracle/wss11_username_token_with_message_protection_client_policy

This policy provides message-level protection and authentication for outbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_username_token_with_message_protection_client_template. See "oracle/wss11_username_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-50.

Properties You Can Configure

See Table C-51.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

How to Set Up the Web Service Client at Design Time

This policy uses symmetric key technology, which is an encryption method that uses the same shared key to encrypt and decrypt data. The symmetric key is used to sign the message.

Configure the policy assertion for message signing, message encryption, or both.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Example 9-5 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.1 standards. In this example, the body element is encrypted.

oracle/wss11_username_token_with_message_protection_service_policy

This policy enforces message-level protection (that is, message integrity and message confidentiality) and authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_username_token_with_message_protection_service_template. See "oracle/wss11_username_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-50.

Properties You Can Configure

See Table C-52.

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

How to Set Up WebLogic Server

Use the WebLogic Server Administration Console to add an Authentication provider of type OAM Authenticator or another Authentication provider to the active security realm for the WebLogic domain in which the Web service is deployed, as described in "Configuring an Authentication Provider in WebLogic Server".

oracle/wss11_x509_token_with_message_protection_client_policy

This policy provides message-level protection and certificate-based authentication for outbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_x509_token_with_message_protection_client_template. See "oracle/wss11_x509_token_with_message_protection_client_template" for more information about the assertion.

Settings You Can Change

See Table C-53.

Properties You Can Configure

See Table C-54.

How to Set Up the Web Service Client

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the Web service keystore, as described in "Setting up the Keystore for Message Protection".

How to Set Up the Web Service Client at Design Time

This policy requires you to set up the Web service client keystore, as described in "Setting Up the Web Service Client Keystore at Design Time". The policy specifically requires that the client's and Web service's respective keystores already contain digital certificates containing each other's public key.

The Web service client needs to provide valid X.509 authentication credentials in the SOAP message through the WS-Security binary security token.

See "Client Programmatic Configuration Overrides" for a description of the configuration settings you can override.

Configure the policy assertion for message signing, message encryption, or both.

Example 9-5 is an example of the typical structure of encryption elements included in the Security header in conformance with the WS-Security 1.1 standards. In this example, the body element is encrypted.

oracle/wss11_x509_token_with_message_protection_service_policy

This policy enforces message-level protection and certificate-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.

This policy contains the following policy assertion: oracle/wss11_x509_token_with_message_protection_service_template. See "oracle/wss11_x509_token_with_message_protection_service_template" for more information about the assertion.

Settings You Can Change

See Table C-53.

Properties You Can Configure

See Table C-55.

How to Set Up Oracle Platform Security Services (OPSS)

Configure the policy assertion for message signing, message encryption, or both.

This policy requires you to set up the keystore, as described in "Setting up the Keystore for Message Protection".

Store the trusted certificate that corresponds to the client's private key (used to sign the message) in the keystore. You also need to store the service's private key in the keystore for decrypting the message, and the CA root certificate.

You must store the password for the decryption key in the credential store, as described in "Configuring the Credential Store Provider" . Use keystore.enc.csf.key as the key name.

How to Set Up WebLogic Server

You need to configure the OAM Authentication provider or another Authentication provider, as described in "Configuring an Authentication Provider in WebLogic Server", and make sure that you provide the X.509 callback information for this provider.

Authorization Policies

Frequently, authentication is the first step of determining whether a user should be given access to a Web service. After the user is authenticated, the second step is to verify that the user is authorized to access the Web service. This is accomplished using an authorization policy. You can create an authorization policy using the binding_authorization_template or the component_authorization_template assertion templates.

Policies created with these templates perform role- or permission-based access control (RBAC) and check that the authenticated user has been granted one of the roles or permissions allowed access to the Web service.

Predefined Policies summarizes the security policies that enforce authorization, and indicates whether the policy is enforced at the transport layer or SOAP header.

Note:

The authorization polices can follow any authentication policy where the subject is established.

You cannot attach both a permitall and denyall policy to the same Web service.

Determining Which Resources to Protect

The authorization policies provide the following properties that you can use to specify which resources you want the policy to protect. Not all of the predefined policies feature all of the properties.

  • Constraint Pattern -- Reserved for future use.

  • Action Pattern -- The Web service operation for which permission-based checks are performed. This value can be a comma-separated list of values. This field accepts wildcards. * means all Web service operations.

    The valid values for Action Pattern are determined by the Web service methods. For example, if the Web service method is validate(amountAvailable), enter the Action Pattern as validate,amountAvailable.

  • Resource Pattern -- The name of the resource for which permission-based checks are performed. This field accepts wildcards, and the default is * for all resources in the Web services protected by the policy.

    By convention you enter the Resource Pattern as (namespace of Web service + Web service name).

    For example, if the namespace of the Web service is http://project11 and the Web service name is CreditValidation, you would enter the Resource Name as http://project11/CreditValidation.

    If you specify a specific Resource Pattern, the policy is enforced only for those Web services that match the criteria. That is, entering a specific Resource Pattern limits the scope of the authorization policy. This condition also applies if you have bulk-attached this authorization policy to multiple subjects. The default of * protects all resources (namespace of Web service + Web service name) of the bulk-attached Web services.

  • Permission Check Class -- By default, it is oracle.wsm.security.WSFunctionPermission. The class must be in the classpath.

  • Authorization Setting -- Possible values are Permit All, Deny All, and Selected Roles. If you choose Selected Roles, you must then select from the enterprise (Global) roles defined in WebLogic Server, which may include the following:

    • AdminChannelUser

    • Anonymous

    • AppTester

    • CrossDomainConnector

    • Deployer

    • Monitor

    • Operator

    • OracleSystemRole

oracle/binding_authorization_denyall_policy

This policy provides a simple role-based authorization policy based on the authenticated subject.

This policy denies all users with any role.

This policy should follow an authentication policy where the subject is established and can be attached to any SOAP-based endpoint.

You must have already configured a WebLogic Authentication provider, as described in "Configure Authentication Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

This policy contains the following policy assertion: oracle/binding_authorization_template

See "oracle/binding_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-57.

To add roles:

  1. Click Add.

  2. To add roles, click the checkbox next to each role you want to add in the Roles Available column and click Move. To add all roles, click Move All.

    To remove roles, click the checkbox next to each role you want to remove in the Roles Selected to Add column, and click Remove. To remove all roles, click Remove All.

    To search for roles, enter a search string in the Role Name search box and click the go arrow. The Roles Available column is updated to include only those roles that match the search string.

  3. Click OK.

To delete roles:

  1. Select the role that you want to delete in the Selected Roles list.

  2. Click Delete.

Properties You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

If you specify one or more of the WebLogic Server enterprise roles, the authenticated subject must already have that role. You use the WebLogic Server Administration Console to grant a role to a user or group, as described in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

oracle/binding_authorization_permitall_policy

This policy provides a simple role-based authorization policy based on the authenticated subject.

This policy permits all users with any roles.

This policy should follow an authentication policy where the subject is established and can be attached to any SOAP-based endpoint.

You must have already configured a WebLogic Authentication provider, as described in "Configure Authentication Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

This policy contains the following policy assertion: oracle/binding_authorization_template. See "oracle/binding_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-57.

To add roles:

  1. Click Add.

  2. To add roles, click the checkbox next to each role you want to add in the Roles Available column and click Move. To add all roles, click Move All.

    To remove roles, click the checkbox next to each role you want to remove in the Roles Selected to Add column, and click Remove. To remove all roles, click Remove All.

    To search for roles, enter a search string in the Role Name search box and click the go arrow. The Roles Available column is updated to include only those roles that match the search string.

  3. Click OK.

To delete roles:

  1. Select the role that you want to delete in the Selected Roles list.

  2. Click Delete.

Properties You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

If you specify one or more of the WebLogic Server enterprise roles, the authenticated subject must already have that role. You use the WebLogic Server Administration Console to grant a role to a user or group, as described in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

oracle/binding_permission_authorization_policy

This policy provides a permission-based authorization policy based on the authenticated subject.

This policy ensures that the subject has permission to perform the operation. To do this, the Authorization Policy executor leverages OPSS to check if the authenticated subject has been granted oracle.wsm.security.WSFunctionPermission (or whatever permission class is specified in Permission Check Class) using the Resource Pattern and Action Pattern as parameters. Resource Pattern and Action Pattern are used to identify if the authorization assertion is to be enforced for this particular request. Access is allowed if the authenticated subject has been granted WSFunctionPermission.

You can grant the WSFunctionPermission permission to a user, a group, or an application role. If you grant WSFunctionPermission to a user or group it will apply to all applications that are deployed in the domain.

This policy should follow an authentication policy where the subject is established and can be attached to any SOAP-based endpoint.

This policy contains the following policy assertion: oracle/binding_permission_authorization_template. See "oracle/binding_permission_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-58.

Attributes You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

Use Fusion Middleware Control to grant the WSFunctionPermission permission to the user, group, or application that will attempt to authenticate to the Web service.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication Providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

oracle/component_authorization_denyall_policy

This policy provides a simple role-based authorization policy based on the authenticated subject.

This policy denies all users with any roles.

You must have already configured a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

This policy should follow an authentication policy where the subject is established and can be attached to any SCA-based endpoint.

This policy contains the following policy assertion: oracle/component_authorization_template. See "oracle/component_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-59.

To add roles:

  1. Click Add.

  2. To add roles, click the checkbox next to each role you want to add in the Roles Available column and click Move. To add all roles, click Move All.

    To remove roles, click the checkbox next to each role you want to remove in the Roles Selected to Add column, and click Remove. To remove all roles, click Remove All.

    To search for roles, enter a search string in the Role Name search box and click the go arrow. The Roles Available column is updated to include only those roles that match the search string.

  3. Click OK.

To delete roles:

  1. Select the role that you want to delete in the Selected Roles list.

  2. Click Delete.

Properties You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

If you specify one or more of the WebLogic Server enterprise roles, the authenticated subject must already have that role. You use the WebLogic Server Administration Console to grant a role to a user or group, as described in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

oracle/component_authorization_permitall_policy

This policy provides a simple role-based authorization policy based on the authenticated subject.

This policy permits all users with any roles.

You must have already configured a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

It should follow an authentication policy where the subject is established and can be attached to any SCA-based endpoint.

This policy contains the following policy assertion: oracle/component_authorization_template. See "oracle/component_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-59.

To add roles:

  1. Click Add.

  2. To add roles, click the checkbox next to each role you want to add in the Roles Available column and click Move. To add all roles, click Move All.

    To remove roles, click the checkbox next to each role you want to remove in the Roles Selected to Add column, and click Remove. To remove all roles, click Remove All.

    To search for roles, enter a search string in the Role Name search box and click the go arrow. The Roles Available column is updated to include only those roles that match the search string.

  3. Click OK.

To delete roles:

  1. Select the role that you want to delete in the Selected Roles list.

  2. Click Delete.

Properties You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

If you specify one or more of the WebLogic Server enterprise roles, the authenticated subject must already have that role. You use the WebLogic Server Administration Console to grant a role to a user or group, as described in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

oracle/component_permission_authorization_policy

This policy provides a permission-based authorization policy based on the authenticated subject.

This policy ensures that the subject has permission to perform the operation. To do this, the Authorization Policy executor leverages OPSS to check if the authenticated subject has been granted oracle.wsm.security.WSFunctionPermission (or whatever permission class is specified in Permission Check Class) using the Resource Pattern and Action Pattern as parameters. Resource Pattern and Action Pattern are used to identify if the authorization assertion is to be enforced for this particular request. Access is allowed if the authenticated subject has been granted WSFunctionPermission.

You can grant the WSFunctionPermission permission to a user, a group, or an application role. If you grant WSFunctionPermission to a user or group it will apply to all applications that are deployed in the domain.

This policy should follow an authentication policy where the subject is established and can be attached to any SCA-based endpoint.

This policy contains the following policy assertion: oracle/component_permission_authorization_template. See "oracle/component_permission_authorization_template" for more information about the assertion.

Settings You Can Change

See Table C-60.

Properties You Can Configure

None defined.

How to Set Up Oracle Platform Security Services (OPSS)

Use Fusion Middleware Control to grant the WSFunctionPermission permission to the user, group, or application that will attempt to authenticate to the Web service.

You must configure a WebLogic Authentication provider, as described in "Configure Authentication providers" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

WS-Addressing Policies

The Web Services Addressing (WS-Addressing) specification (http://www.w3.org/TR/ws-addr-core/) provides transport-neutral mechanisms to address Web services and messages. In particular, the specification defines a number of XML elements used to identify Web service endpoints and to secure end-to-end endpoint identification in messages.

This section describes the predefined WS-Addressing policies.

oracle/wsaddr_policy

This policy causes the platform to check inbound messages for the presence of WS-Addressing headers conforming to the W3C 2005 Final WS-Addressing Policy standard. In addition, it causes the platform to include a WS-Addressing header in outbound SOAP messages.

How to Set Up the Web Service Client

No configuration is needed.

How to Set Up the Web Service Client at Design Time

Configure WS-Addressing for the Web service client as described in the Web Services Addressing 1.0 - SOAP Binding specification (http://www.w3.org/TR/ws-addr-soap/).

How to Set Up Oracle Platform Security Services (OPSS)

No configuration is needed.

MTOM Attachment Policies

This section describes the predefined MTOM policies.

oracle/wsmtom_policy

SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging (MTOM/XOP) defines a method for optimizing the transmission of XML data of type xs:base64Binary or xs:hexBinary in SOAP messages.

The Message Transmission Optimization Mechanism (MTOM) policy rejects inbound messages that are not in MTOM format and verifies that outbound messages are in MTOM format.

MTOM refers to specifications http://www.w3.org/TR/2005/REC-soap12-mtom-20050125 and http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405 for SOAP 1.2 and SOAP 1.1 bindings, respectively.

How to Set Up the Web Service Client

No configuration is required.

How to Set Up the Web Service Client at Design Time

To enable MTOM on the client of the Web service, pass the javax.xml.ws.soap.MTOMFeature as a parameter when creating the Web Service proxy or dispatch, as illustrated in the following example.

package examples.webservices.mtom.client;
import javax.xml.ws.soap.MTOMFeature;
public class Main {
  public static void main(String[] args) {
    String FOO = "FOO";
    MtomService service = new MtomService()
    MtomPortType port = service.getMtomPortTypePort(new MTOMFeature());
    String result = null;
    result = port.echoBinaryAsString(FOO.getBytes());
    System.out.println( "Got result: " + result );
  }
}

How to Set Up Oracle Platform Security Services (OPSS)

No configuration is required.

Reliable Messaging Policies

WS-ReliableMessaging makes message exchanges reliable. It ensures that messages are delivered reliably between distributed applications regardless of software component, system, or network failures. Ordered delivery is assured and automatic retransmission of failed messages does not have to be coded by each client application.

Consider using reliable messaging if your Web service is experiencing the following problems:

  • network failures or dropped connections

  • messages are lost in transit

  • messages are arriving at their destination out of order

WS-ReliableMessaging considers the source and destination of a message to be independent of the client/server model. That is, the client and the server can each act simultaneously as both a message source and destination on the communications path.

This section describes the predefined Reliable Messaging policies.

WS-RM Policy Properties

Table 9-4 lists the properties that you can set for the WS-RM policies.

Table 9-4 WS-RM Policy Properties

Property Name Default Value Used by Policy Possible Values

DeliveryAssurance

inorder

InOrder

AtLeastOnce

AtLeastOnceInOrder

ExactlyOnce

ExactlyOnceInOrder

AtMostOnce

AtMostOnceInOrder

StoreType

inmemory

InMemory

FileSystem (not fully supported)

JDBC

jdbc-connection-name

Provides connection information for JDBC type message store. The JNDI reference to a JDBC data source, take the precedence over jdbc-connection-url. The username and password will be used if both present.

   

StoreName

oracle

String value

InactivityTimeout

The amount of time in milliseconds allowed to elapse between message exchanges associated with a particular WS-RM sequence, after which, the sequence will be automatically terminated and discarded.

600000

The amount of time in milliseconds.

BaseRetransmissionInterval

3000

 

oracle/wsrm10_policy

This policy provides support for version 1.0 of the Web Services Reliable Messaging protocol. This policy can be attached to any SOAP-based client or endpoint.

How to Set Up the Web Service Client

The Web service client will automatically detect the WSDL policy assertions at runtime and use them to enable the advertised version of WS-RM on the client.

How to Set Up the Web Service Client at Design Time

For multi-message sequences, the client code must include explicit invocations of methods for delimiting sequence boundaries. Otherwise, every message is wrapped in its own sequence

Edit the client to enable a reliable messaging session for the messages sent to the service. The oracle.webservices.rm.client.RMSessionLifecycle interface provides the client with a mechanism for demarcating WS-RM sequence boundaries.

Example 9-6 illustrates sample WS-RM client code. In the code, a new TestService is created. The TestPort, through which the client will communicate with the service, is retrieved. The port object is cast to a RMSessionLifecycle object and a reliable messaging session is opened on it (openSession). After the messages are sent to the service, the session is closed (closeSession).

Example 9-6 Sample WS-Rm Client Code

public class ClientServlet extends HttpServlet {
 
    public void doGet(HttpServletRequest request, 
                HttpServletResponse response) throws ServletException, 
                                                          IOException {
 
        int num1 =  Integer.parseInt(request.getParameter("num1"));
        int num2 =  Integer.parseInt(request.getParameter("num2"));
        String outputStr = null;
 
        TestService service = new TestService();
        Test port = service.getTestPort();
 
        try {
        ((RMSessionLifecycle) port).openSession();
            outputStr = port.hello(inputStr);            
        } catch (Exception e) {
            e.printStackTrace();  
            outputStr = e.getMessage();
        } finally {
        ((RMSessionLifecycle) port).closeSession();
            response.getOutputStream().write(outputStr.getBytes());
        }
    }
}

How to Set Up Oracle Platform Security Services (OPSS)

No additional configuration is required.

oracle/wsrm11_policy

This policy provides support for version 1.1 of the Web Services Reliable Messaging protocol. This policy can be attached to any SOAP-based client or endpoint.

How to Set Up the Web Service Client

The Web service client will automatically detect the WSDL policy assertions at runtime and use them to enable the advertised version of WS-RM on the client.

How to Set Up the Web Service Client at Design Time

For multi-message sequences, the client code must include explicit invocations of methods for delimiting sequence boundaries. Otherwise, every message is wrapped in its own sequence

Edit the client to enable a reliable messaging session for the messages sent to the service. The oracle.webservices.rm.client.RMSessionLifecycle interface provides the client with a mechanism for demarcating WS-RM sequence boundaries.

Example 9-6 illustrates a servlet client. In the code, a new TestService is created. The TestPort, through which the client will communicate with the service, is retrieved. The port object is cast to a RMSessionLifecycle object and a reliable messaging session is opened on it (openSession). After the messages are sent to the service, the session is closed (closeSession).

How to Set Up Oracle Platform Security Services (OPSS)

No additional configuration is required.

Management Policies

This section describes the predefined Management policies.

oracle/log_policy

This policy causes the request, response, and fault messages to be sent to a message log.

This policy contains the following policy assertion: oracle/log_template. See "oracle/security_log_template" for more information about the assertion.

Settings You Can Change

See Table C-62.

Properties You Can Configure

None defined.

How to Set Up the Web Service or Client

Determine whether you want to log messages for the request and response, based on the following categories:

  • all

  • header

  • SOAP body

  • SOAP envelope

How to Set Up Oracle Platform Security Services (OPSS)

Messages are logged to the message log for the domain.

To view the message log

  1. In the navigator pane, expand WebLogic Domain to show the domain for which you want to see the logged messages. Select the domain.

  2. Using Fusion Middleware Control, click Weblogic Domain, then Logs and then View Log Messages.