Configure OpenSSO STS. as described Configure the STS policy following the steps described in

10-84 Oracle Fusion Middleware Security and Administrators Guide for Web Services 11 Configuring Policies 11-1 11 Configuring Policies This chapter discusses how to configure policies in Web services and Web service clients to achieve Quality of Service QoS requirements. 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 ■ Protecting Messages ■ Authentication-Only Policies and Configuration Steps ■ Message Protection-Only Policies and Configuration Steps ■ Message Protection and Authentication Policies and Configuration Steps ■ Authorization Policies and Configuration Steps ■ WS-Addressing Policies and Configuration Steps ■ WS-Trust Policies ■ MTOM Attachment Policies and Configuration Steps ■ Reliable Messaging Policies and Configuration Steps ■ Management Policies and Configuration Steps ■ Attaching Policy Files to Web Services and Clients ■ Using Client Programmatic Configuration Overrides ■ Configuring Local Optimization for a Policy 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. a. Do you require authentication only? If yes, then go to step 2. b. Do you require authorization only? If yes, then see Authorization Policies and Configuration Steps on page 11-60 11-2 Oracle Fusion Middleware Security and Administrators Guide for Web Services c. Do you require authentication and authorization? If yes, then go to step 3. d. Do you only require message protection? If yes, then see Message Protection-Only Policies and Configuration Steps on page 11-13. e. 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: a. Where will the token be inserted? Will the token to be inserted in the transport layer or in a SOAP header? b. Do you need to use a particular type of token? The supported credentials for authentication-only policies are usernamepassword, SAML, and Kerberos tokens.

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

following: a. Review the considerations provided for authentication in step 2. b. Review Authorization Policies and Configuration Steps on page 11-60 for more information about authorization policies.

4. If you require both authentication and message protection, then you need to

consider the following: a. 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: usernamepassword, SAML, and X.509 certificates. For more information, see Message Protection and Authentication Policies and Configuration Steps on page 11-19. 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 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. Configuring Policies 11-3 ■ 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 Configuring Keystores for Message Protection on page 10-8. 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 identities of the sending and receiving parties. The sender uses the recipients public key to encrypt the message. Only the recipients private key can successfully decrypt the message, ensuring that it cannot be read by third parties while in transit. The Web services base64-encoded public certificate is published in the WSDL for use by the Web service client, as described in Using Service Identity Certification Extension on page 10-37. 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 senders private key. When the message is received, the recipient decrypts the hash using the senders public key. 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 recipients 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. You can require that the entire body be signed, encrypted, or both, or identity specific header and body elements. The following is an example of partial encryption. 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 senders 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.