If you will be using policies that involve signatures related to SAML assertions

10-48 Oracle Fusion Middleware Security and Administrators Guide for Web Services You might have a scenario in which your SOA application needs to specify which user identity to use in client-side Web service policies, and then dynamically switch the user associated with the SAML token in the outbound Web service request. Instead of using the username from the Subject, this policy allows you to set a new user name when sending the SAML Web service request. The wss11_saml_token_identity_switch_with_message_protection_ client_policy policy creates the SAML token based on the user ID set via the property javax.xml.ws.security.auth.username. Consider the following use case in which a Web service client calls a SOA application, which in turn becomes the client for a Web service. client - SOA - web service In this use case: ■ The client is secured with the wss11_username_with_message_protection_ client_policy policy. It communicates with the SOA entry point as user end_user1. ■ The SOA entry point is protected by wss11_username_with_message_ protection_service_policy. The SOA application authenticates the end user and establishes the Subject based on end_user1. However, it wants to propagate a different identity to the external Web service. Therefore, to do identity switching, attach the wss11_saml_identity_ switch_message_protection_client_policy policy to the SOA reference binding component. ■ The username that is propagated is determined dynamically by the BPEL process, which is a component in the SOA application. The username is set as BPEL property javax.xml.ws.security.auth.username with the dynamically determined username value. The external Web service can be protected by wss11_saml_with_message_protection_service_policy. It receives the switched user and not end_user1. ■ A similar scenario can be used by a J2EE application replacing SOA in this scenario with the J2EE application that establishes the Subject based on an end user but then needs to propagate a different identity. In case of J2EE, you can set the user name programmatically as follows: BindingProvider port.getRequestContext.putBindingProvider.USERNAME_ PROPERTY, config.getUSERNAME; ■ Use Fusion Middleware Control to add the WSIdentityPermission permission to the SOA reference binding component. The wss11_saml_token_identity_switch_with_message_protection_ client_policy policy requires that an application to which the policy is attached must have the WSIdentityPermission permission. That is, applications from which Oracle WSM accepts the externally-supplied identity must have the WSIdentityPermission permission. This is to avoid potentially rogue applications from providing an identity to Oracle WSM. Setting Up Your Environment for Policies 10-49 Set the javax.xml.ws.security.auth.username Property For SOA: The SOA composite has a BPEL process as one SOA service component. A BPEL process provides process orchestration and storage of synchronous and asynchronous processes. You can define a BPEL property with the exact name javax.xml.ws.security.auth.username. The value for this property can be the identity that the SOA application wants to propagate, which could potentially be determined dynamically by the BPEL process. For J2EE: Set the BindingProvider.USERNAME_PROPERTY property. Set the WSIdentityPermission Permission The Web service client for example, the SOA reference binding component to which you attached the wss11_saml_token_identity_switch_with_message_ protection_client_policy policy must have the oracle.wsm.security.WSIdentityPermission permission. To use Fusion Middleware Control to add the oracle.wsm.security.WSIdentityPermission permission to the SOA reference binding component as a System Grant, perform the following steps:

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