Click Add to define a corresponding csf-key credential property. In the Add

14-20 Oracle Fusion Middleware Security and Administrators Guide for Web Services Tuning Web Service Security Policy Enforcement The BindingSecurityInterceptor property on the Policy Interceptors tab allows you to tune security policy enforcement by adjusting the default message timestamp skews between system clocks, the time-to-live for nonce messages in the policy cache, and the message expiration time. Perform the following steps to tune the security policy enforcement: 1. Access the Platform Policy Configuration page, as described in Configuring Platform Policy Properties on page 14-15.

2. Select the Policy Interceptors tab.

3. Select the BindingSecurityInterceptor security property on the list. 4. To modify a BindingSecurityInterceptor security property, select it and then click Edit. In the Edit Property window, you can edit the Value field to change the default amount for each property. a. agent.clock.skew – Tolerance of time differences, in seconds, between client and server machines. For example, when timestamps are sent across in a message to a service that follows a different time zone, this property allows for the specified time tolerance. The default value is 300 seconds. Increase agent.clock.skew when: – The servers clock is ahead of the clients clock: If the server’s clock is ahead of the client’s clock then increase the agent.clock.skew. For example, if the server’s clock is ahead of the client’s clock by 10 minutes, then increase the server’s agent.clock.skew to 10 minutes. – The clients clock is ahead of the servers clock: If the client’s clock is ahead of the server’s clock then increase the agent.clock.skew. For example, if the client’s clock is ahead of the server’s clock by 10 minutes, then increase the server’s agent.clock.skew to 10 minutes. b. agent.nonce.ttl – Total time-to-live, in seconds, for nonce in the cache when nonce is sent across in a message. This property caches the nonce and once this duration is over, the nonce is removed from the cache. The default value is 28800 seconds. c. agent.expire.time – Duration of time, in seconds, before a message expires after its creation. This property is used in cases where a timestamp is sent across in the SOAP header to verify if the timestamp has expired or not. The default value is 300 seconds. If the message expires when received by the service even when there is no time difference between the client’s and service’s clocks, then the message expiry time must be increased. The message expiry time is derived from the values of agent.expiry.time and the expiry time in the incoming message, and is the lesser of the two. For example, if the servers agent.expiry.time is set to 5 minutes and expiry time in the incoming message expiry time is 6 minutes, then the agent.expiry.time at the service side must be increased. On the other hand, if the servers agent.expiry.time is 5 minutes and the incoming message expiry time is 3 minutes, then the expiry time in the incoming message that is, at the client side must be increased. A higher value of the agent.expiry.time may lead to a security vulnerability

d. Click OK.

5. To delete an existing property, select it and then click Delete.

Advanced Administration 14-21

6. Click Apply to apply the property updates.

Defining Identity Extension Properties The properties on the Identity Extension tab enable you to specify whether to enforce Web service policies by publishing the X509 certificate in the WSDL. If there is no need to publish the X509 certificate for example, with SSL, you can override the default setting to avoid publishing the certificate. In addition, if the X509 is published, you can also specify whether to ignore the hostname verification feature. For more information, see Using Service Identity Certification Extension on page 10-37. Defining a Trusted Distinguished Name List for SAML Signing Certificates The Trusted SAML clients and Trusted STS servers tabs enable you to define a list of trusted distinguish names DNs for SAML signing certificates. By default, Oracle WSM checks the incoming issuer name against the list of configured issuers, and checks the SAML signature against the configured certificates in the Oracle WSM keystore. If you define a trusted DNs list, Oracle WSM also verifies that the SAML signature is signed by the particular certificates that is associated with that issuer. Configuration of the trusted DNs list is optional; it is available for users that require more fine-grained control to associate each issuer with a list of one or more signing certificates. If you do not define a list of DNs for a trusted issuer, then Oracle WSM allows signing by any certificate, as long as that certificate is trusted by the certificates present in the Oracle WSM keystore. Imporant Notes : ■ Using the Trusted SAML clients and Trusted STS servers tabs, you define the DNs of the signing certificates, not the certificates themselves. ■ The certificate must be imported into the Oracle WSM keystore or included in the message. If the certificate is provided in the message, its issuer must be imported into the Oracle WSM keystore. ■ For two-way SSL: – The certificate needs to be imported into the Java EE container’s trust store. – The DN of the client SSL certificates are used for validation and need to be present in the trusted DNs list. ■ In all cases, the signing certificates must be trusted by the certificates present in the OWSM keystore. To defined a trusted DNs list for SAML signing certificates: 1. Configure the trusted SAML issuers, as described in Configuring SAML on page 10-43. Optionally, you can override the SAML issuer when attaching the policy. For more information, see Attaching Client Policies Permitting Overrides on page 8-21. 2. Access the Platform Policy Configuration page, as described in Configuring Platform Policy Properties on page 14-15.