In the Permissions section of the page, select the starting point permission class

Setting Up Your Environment for Policies 10-51 ■ oraclewss11_kerberos_token_with_message_protection_client_policy ■ oraclewss11_kerberos_token_with_message_protection_service_policy ■ oraclewss11_kerberos_token_with_message_protection_basic128_client_policy ■ oraclewss11_kerberos_token_with_message_protection_basic128_service_policy You may also create a policy using the following assertion templates: ■ oraclewss11_kerberos_token_client_template ■ oraclewss11_kerberos_token_service_template ■ oraclewss11_kerberos_token_with_message_protection_client_template ■ oraclewss11_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 Key Distribution Center KDC for use by the Web service client and Web service. You can also use Microsoft Active Directory with KDC. See Using Active Directory with Kerberos and Message Protection on page 10-55. Initializing and Starting the MIT Kerberos KDC Initialize KDC database. For example, on UNIX you might run the following command as root, where oracle.com is your default realm: root usrkerberossbinkrb5_util -r oracle.com -s Start the kerberos service processes. For example, on UNIX you might run the following commands as root.: root usrkerberossbinkrb5kdc root usrkerberossbinkadmind 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 usrkerberossbinkadmin.local kadmin.localaddprinc fmwadmin -pw welcome1 kadmin.local addprinc SOAPmyhost.oracle.com -randkey kadmin.locallistprincs to see the added principals The Web service principal name SOAPmyhost.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. 10-52 Oracle Fusion Middleware Security and Administrators Guide for Web Services 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 etckrb5.conf for UNIX hosts, and at C:\windows\krb5.ini for Windows hosts. A sample krb5.conf is shown in Example 10–7 . Note the following: ■ The file tells the kerberos run time 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 – default_tgs_enctypes – permitted_enctypes The order of cipher suites is significant and should comply with the algorithm suite used in the client-side Kerberos policy. For example, if the KDC-supported enc-types are des3-cbc-sha1, des-cbc-md5, des-cbc-crc, arcfour-hmac, then the following order of enc-types entries should be used in clients krb5.conf for the following policies: – wss11_kerberos_with_message_protection_client_policy: default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac – wss11_kerberos_with_message_protection_basic128_client_policy: default_tkt_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tgs_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc permitted_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc Example 10–7 Sample krb5.conf File [logging] default = FILE:varlogkrb5libs.log kdc = FILE:varlogkrb5kdc.log admin_server = FILE:varlogkadmind.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 arcfour-hmac default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac [realms] oracle.com = Setting Up Your Environment for Policies 10-53 {kdc = someadminserver.com:88 admin_server = someadminserver.com:749 default_domain = us.oracle.com } [domain_realm] us.oracle.com = oracle.com [kdc] profile = varkerberoskrb5kdckdc.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 on page 10-51. 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 HOSTlocalhostoracle.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 on page 10-51. Use a configuration override to specify the service principal name at design time, as follows: JAX-WS Clients: BindingProviderport.getRequestContext.putSecurityConstants.ClientConstants. WSSEC_KERBEROS_SERVICE_PRINCIPAL, SOAPmyhost.oracle.comoracle.com; Configuring the Web Service to Use the Correct KDC Configure the Web service to authenticate against the correct KDC. The configuration for the KDC resides at etckrb5.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 10–7 . 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. 10-54 Oracle Fusion Middleware Security and Administrators Guide for Web Services 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.localktadd -k tmpkrb5.keytab SOAPmyhost.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 on page 10-40 to identify the location of the Web service KDC file. For example, assume that the keytab file is installed at scratchmyhomekrb5.keytab. Note the changes for the keytab and principal properties: ■ principal value=SOAPmyhost.oracle.comoracle.com ■ useKeyTab value=true ■ storeKey value=true ■ keyTab value=scratchmyhomekrb5.keytab ■ doNotPrompt value=true Authenticating the User Corresponding to the Service Principal The Web services run time 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 on page 10-39. 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 SOAPmyhost.oracle.comoracle.com. In this example, a user with the name SOAPmyhost.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: tmpkrb5cc_36687 Default principal: fmwadminoracle.com, 1 entry found. [1] Service Principal: krbtgtoracle.comoracle.com Valid starting: Sep 28, 2007 17:20 Expires: Sep 29, 2007 17:20 Encryption type: DES3 CBC mode with SHA1-KD Setting Up Your Environment for Policies 10-55 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 . 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. Using Active Directory with Kerberos and Message Protection You can use Microsoft Active Directory with the Key Distribution Center KDC as your KDC. This section describes how to configure the KDC through Active Directory for use with Kerberos and message protection. This section assumes that you are already familiar with Active Directory. See your Active Directory documentation for additional details. Setting Up the Web Service Client This section describes the following tasks: ■ Create a User Account on page 10-55 ■ Create a Keytab File on page 10-55 ■ Set the Service Principal Name on page 10-55 Create a User Account Use Active Directory to create a new user account. Do not use DES encryption. By default, the user account is created with RC4-HMAC. For example, you might create a user testpol with the user logon name testtestpol. The user logon name should be of the form containername. You can create the account in any container. Create a Keytab File Use ktpass to create a keytab file: ktpass -princ testtestpol{domain} -pass {...} -mapuser testpol -out testpol.keytab -ptype KRB5_NT_PRINCIPAL -target {domain} where testtestpol is the Service Principal Name and it is mapped to the user testpol. Do not set desonly or cyrpto as des-cbc-crc. Set the Service Principal Name Use setSpn to map the Service Principal Name to the user: setSpn -A testtestpol testpol setSpn -L testpol this should display the availabel mapping There should be only one Service Principal Name mapped to the user. If there are multiple Service Principal Names mapped to the user, remove them using setSpn -D spname username. 10-56 Oracle Fusion Middleware Security and Administrators Guide for Web Services Set Up the Web Service Perform the following steps to set up the Web service:

1. Attach the Kerberos policy to your Web service.

2. Configure the Web service client to authenticate against the right KDC.

The configuration for the KDC resides at etckrb5.conf for UNIX hosts, and at C:\windows\krb5.ini for Windows hosts. Configure the default domain and realm in the krb5.conf or krb5.ini file. Enable the RC4-HMAC encryption type available in JDK6. [libdefaults] default_tkt_enctypes = rc4-hmac default_tgs_enctypes = rc4-hmac permitted_enctypes = rc4-hmac

3. Export the keytab file you created in

Create a Keytab File on page 10-55 to the system where the Web service is hosted. The keytab is a binary file; if you ftp it, use binary mode.

4. Verify the keytab file using kinit:

kinit -k -t absolute path the the keytab file Service Principal Name 5. Modify the krb5 login module as described in Configuring the SAML and Kerberos Login Modules on page 10-40 to specify the keytab location and the Service Principal Name. Use the absolute path to the keytab file. Also, be sure to add realmname to the Service Principal Name. For example: principal value=testtestpoloracle.com SAML Message Protection Use Case Assume that you have a Web service client that you want to protect with the wss11_ saml_token_with_message_protection_client_policy policy, and a corresponding Web service that you want to protect with the wss11_saml_token_with_message_ protection_service_policy policy. This section steps through the procedure for using these two policies. The following topics are described: ■ What You Need to Know on page 10-57 – Requirements of the wss11_saml_token_with_message_protection_service_ policy Policy on page 10-57 – How Are Messages Protected Via Symmetric Keys? on page 10-57 – What Keys Must Be in the Keystore? on page 10-58 – Multi-Domain Use Case Keystore Hardening on page 10-58 – When to Override the SAML Issuer on page 10-59 ■ Main Steps on page 10-59 – Create a WebLogic Server User on page 10-60 – Create a Java Keystore on page 10-61 Setting Up Your Environment for Policies 10-57 – Configure the Web Services Manager Keystore on page 10-61 – Store the Password for the Decryption Key in the Credential Store on page 10-62 – Attach the Policy to Your Web Service on page 10-62 – Attach the Policy to Your Web Service Client on page 10-62 What You Need to Know This section describes what you need to know to configure this SAML message protection use case. The following topics are described: ■ Requirements of the wss11_saml_token_with_message_protection_service_policy Policy on page 10-57 ■ How Are Messages Protected Via Symmetric Keys? on page 10-57 ■ What Keys Must Be in the Keystore? on page 10-58 ■ Multi-Domain Use Case Keystore Hardening on page 10-58 ■ When to Override the SAML Issuer on page 10-59 Requirements of the wss11_saml_token_with_message_protection_service_policy Policy wss11_saml_token_with_message_protection_service_policy enforces message-level protection that is, message integrity and message confidentiality, and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard. Messages are protected using WS-Securitys Basic 128 suite of symmetric key technologies, specifically RSA key mechanisms for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption. For more information about the available algorithms for message protection, see Supported Algorithm Suites on page C-93. Therefore, when you use the keytool or other tool to create the signature and encryption keys needed by this policy, you need to make sure you use the RSA key mechanism, the SHA-1 algorithm, and AES-128 bit encryption to satisfy the policy requirements for the key. How Are Messages Protected Via Symmetric Keys? This policy uses symmetric key technology. Symmetric key cryptography relies on a single, shared secret key, as follows: 1. The client creates the symmetric key, uses it to sign and encrypt the message, and shares it with the Web service in the request message. To protect the symmetric key, the symmetric key sent in the request message is encrypted using the services certificate. 2. The Web service uses the symmetric key in the request message to verify the signature of the request message and decrypt it, and to then sign and encrypt the response message. Consider the following process flow. 10-58 Oracle Fusion Middleware Security and Administrators Guide for Web Services To create the request, the Oracle WSM agent does the following: 1. Generates the shared symmetric key and uses it to both sign and encrypt the request message. 2. Uses its own private key to endorse the signature of the request message. 3. Uses the Web services public key to encrypt the symmetric key. 4. Sends the symmetric key along with the request to the Web service. The client sends its public key in the request so that the Web service can verify the endorsement. When the Web service gets the request, it does the following: 1. Uses its private key to decrypt the symmetric key. 2. Uses the symmetric key to decrypt the request message and to verify its signature. 3. Uses the clients public key in the request message to verify the endorsement signature. To send the response back to the client, the Web service does the following: 1. Uses the same client-generated symmetric key sent along with the request to sign the response message. 2. Uses the same client-generated symmetric key to encrypt the response message. When the Oracle WSM agent receives the response message, it does the following: 1. Uses the symmetric key it generated initially to decrypt the response message. 2. Uses the symmetric key it generated initially to verify signature of the response message. What Keys Must Be in the Keystore? If the client and Web service are in the same domain with access to the same keystore, they can share the same privatepublic key pair. That is, the client can use the private key “orakey” to endorse the signature of the request message and the public key “orakey” to encrypt the symmetric key. The Web service in turn uses the public key “orakey” to verify the endorsement, and the private key “orakey” to decrypt the symmetric key. For demonstration purposes, this use case creates one key pair. Multi-Domain Use Case Keystore Hardening If the client and Web service are not in the same domain and do not have access to the same keystore, the client and Web service must each have a privatepublic key pair. Consider the following requirements in a multiple-domain use case, as shown in Table 10–2 . Table 10–2 Multiple-Domain Use Case Requirements Web Service Client Web Service Needs its own privatepublic key pair in the client keystore. Needs its own privatepublic key pair in the service keystore.