In the Custom Properties section of the page, configure any custom properties for

Setting Up Your Environment for Policies 10-43 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: ■ oraclewss_saml_token_bearer_over_ssl_server_policy ■ oraclewss_saml_token_bearer_over_ssl_client_policy ■ oraclewss_saml_token_over_ssl_service_policy ■ oraclewss_saml_token_over_ssl_client_policy ■ oraclewss10_saml_token_service_policy ■ oraclewss10_saml_token_client_policy ■ oraclewss10_saml20_token_service_policy ■ oraclewss10_saml20_token_client_policy ■ oraclewss10_saml_token_with_message_protection_client_policy ■ oraclewss10_saml_token_with_message_protection_service_policy ■ oraclewss10_saml20_token_with_message_protection_client_policy ■ oraclewss10_saml20_token_with_message_protection_service_policy ■ oraclewss10_saml_token_with_message_protection_ski_basic256_client_policy useKeyTab True or false. Set this to true if you want the module to get the principals 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 principals key to be stored in the Subjects private credentials. keyTab Set this to the file name of the keytab to get principals 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. Table 10–1 Cont. SAML and Kerberos Login Modules Attributes and Properties Login Module Service Name Property Description 10-44 Oracle Fusion Middleware Security and Administrators Guide for Web Services ■ oraclewss10_saml_token_with_message_protection_ski_basic256_service_policy ■ oraclewss10_saml_hok_token_with_message_protection_service_policy ■ oraclewss10_saml_hok_token_with_message_protection_client_policy ■ oraclewss10_saml_token_with_message_integrity_service_policy ■ oraclewss10_saml_token_with_message_integrity_client_policy ■ oraclewss11_saml_token_with_message_protection_service_policy ■ oraclewss11_saml_token_with_message_protection_client_policy ■ oraclewss11_saml20_token_with_message_protection_service_policy ■ oraclewss11_saml20_token_with_message_protection_client_policy The following sections provide more information about SAML configuration: ■ How the SAML Token is Validated on page 10-44 ■ How to Configure SAML Web Service Client at Design Time on page 10-44 ■ Including User Attributes in the Assertion on page 10-45 ■ Including User Roles in the Assertion on page 10-46 ■ How to Configure Oracle Platform Security Services OPSS for SAML Policies on page 10-46 ■ Adding an Additional SAML Assertion Issuer Name on page 10-47 ■ Configuring SAML Web Service Clients for Identity Switching on page 10-47 ■ Defining a Trusted Distinguished Names List for SAML Signing Certificates on page 10-50 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 to complete the perimeter authentication. Which Authentication Provider is Used? Any configured Identity Assertion provider that handles the NameCallback, as described in Configuring an Authentication Provider in WebLogic Server on page 10-39 can then be invoked. The 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. Setting Up Your Environment for Policies 10-45 Configure the Username for the SAML Assertion For a JSE client application, configure the username as a BindingProvider property: MapString,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 Java EE 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 Java EE application and you are making a Web service call from that Java EE 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 Attributes in the Assertion SAML client policies include the user.attributes property that you can use to add user attributes to the SAML assertion. To do this, you specify the attributes to be included as a comma-separated list. For example, attrib1,attrib2. The attribute names you specify must exactly match valid attributes in the configured identity store. user.attributes requires that the Subject is available and subject.precedence is set to true. The Oracle WSM runtime reads the values for these attributes from the configured identity store, and then includes the attributes and their values in the SAML assertion. The user.attributes property is supported for a single identity store, and by default only the first identity store in the list is used. The user must therefore exist and be valid in the identity store used by the configured WebLogic Server Authentication provider. Authentication providers are described in Configuring an Authentication Provider in WebLogic Server on page 10-39. If you have more than one identity store configured, and you want to search for the user in all identity stores, follow these steps to enable searching in all configured identity stores.

1. In the navigator pane, expand WebLogic Domain to show the domain for which

you need to configure the identity store provider. Select the domain.

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

then Security Provider Configuration. 3. In the Identity Store Provider section of the page, click Configure to configure parameters that interact with the identity store. The Identity Store Configuration page is displayed, as shown in Figure 10–12 . 10-46 Oracle Fusion Middleware Security and Administrators Guide for Web Services Figure 10–12 Identity Store Configuration Page

4. Click Add to add a custom property.

5. Add the property virtualize with a value of true, as shown in Figure 10–13 . Figure 10–13 Adding the virtualize property

6. Click OK to submit the changes.

7. Restart Fusion Middleware Control.

Including User Roles in the Assertion You can pass the users 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. 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 on page 10-40. By default, the SAML assertion issuer name is www.oracle.com. The saml.issuer.name client 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. See Adding an Additional SAML Assertion Issuer Name on page 10-47 for information on adding an additional issuer.

2. Configure the 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 Setting Up Your Environment for Policies 10-47 certificates for signing and verification, as described in Configuring Keystores for Message Protection on page 10-8. 4. If you will be using policies that require SSL, you need to configure SSL, as described in Configuring Keystores for SSL on page 10-22. Adding an Additional SAML Assertion Issuer Name The SAML issuer name is generally 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. There are two circumstances in which you need to add additional issuers: ■ For a SAML predefined Web service policy or assertion, you set a value for the saml.trusted.issuer property. If you set a value for this property, you must add that trusted issuer to the Issuers list. ■ For a SAML client-side policy or assertion, you set a value for the saml.issuer.name property. If you set a value for this property, you must add that trusted issuer to the Issuers list with the same value. ■ If a different client, for instance .NETSTS, is talking to a Web service protected by a predefined SAML policy, then you need to add that issuer to the Issuers list. To add an additional SAML assertion issuer to the Issuers list:

1. In the navigator pane, expand WebLogic Domain to show the domain for which