Configuration Guides › Policy Server Configuration Guide › Authentication Schemes › WS‑Security Authentication › Configure the WS‑Security Authentication Scheme

Configure the WS‑Security Authentication Scheme

To obtain security information from WS‑Security headers in incoming XML messages, you must configure the WS‑Security authentication scheme.

Note: The following procedure assumes you are creating a new object. You can also copy the properties of an existing object to create an object. More information exists in Duplicate Policy Server Objects.

To configure the authentication scheme

1. Click Infrastructure, Authentication.
2. Click SOA Authentication Scheme, Create SOA Authentication Scheme.

   The Create Authentication Scheme pane opens.

3. Click OK.

   Authentication scheme settings open.

   Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

4. Enter a name and a description for the scheme in the General group box.
5. Select WS‑Security from the Authentication Scheme Type list.
6. Specify a protection level.
7. In the Scheme Setup group box, select one of the following required Security Token Types:
   • Username and Password Digest (the default). Also valid for Username and Password tokens (clear text).
   • X509v3 Certificate
   • SAML Assertion

   If you select Username and Password Digest or X509v3 Certificate, the XML Signature Restrictions group box is activated. If you select SAML Assertion, the SAML Token Restrictions group box is activated.

8. If you selected the Username and Password Digest or X509v3 Certificate security token type, specify how restrictions should be applied in the XML Signature Restrictions group box:
   • No Signature Required (the default)
   • Must Cover Entire Document
   • Must Cover Body of Message
   • Only Needs to Apply to Headers
9. If you selected the SAML Assertion security token type, locate the SAML Token Restrictions group box and complete the following fields to specify how token restrictions should be applied:
   • Audience

     (Optional for SAML 1.1; required for SAML 2.0) Specifies a required value for a SAML assertion token’s <saml:Audience> element. If left undefined, no restriction is placed on the Audience element’s content.

   • Attribute Name/XPATH

     (Optional) Specifies an XPATH expression that can be used to obtain a user identity value if the user identity in the assertion token’s saml:NameIdentifier element (which is used by default) is not suitable for authentication. The default behavior tends to be sufficient for associated non-LDAP user directories and SOA Security Manager-generated SAML tokens.

     For LDAP user directories, specify an XPATH expression that returns a user identity value that will resolve correctly. For example:

     //SMlogin/Username/text()

     For SAML tokens not generated by SOA Security Manager (which may place other information, such as E-mail addresses in the saml:NameIdentifier element), you should also specify an XPATH expression that extract only the required information.

     If you need to strip standard prefixes to return the required attribute value itself, see Stripping Standard Prefixes from XPath Queries.

   • Attribute Search String

     If you specified an Attribute Name/XPATH expression in the field above, specifies a search string to apply to the result of the XPATH expression to obtain a user’s DN in the Attribute Search String field.

     For LDAP user directories, this search string should be in the form:

     	attribute=LDAP:uid=%s
     

     (You may need to modify the “uid=%s” component depending on how lookups are performed in a specific directory.)

   • Allow sender-vouches

     (Optional) Require digitally signed SAML assertions created with the sender-vouches subject confirmation method.

   • Allow holder-of-key

     (Optional) Require digitally signed SAML assertions created with the holder-of-key subject confirmation method.

     Note: Select Allow sender-vouches and Allow holder-of-key options to allow signed assertions created with either confirmation method. Select neither option to allow unsigned SAML assertions.

   • Use SSL Keystore

     (Optional) Configures SOA Security Manager to use the web server’s SSL keystore to validate the assertion certificate instead of its own keystore.

10. Configure the following other fields as necessary:
    • Issuer certificate match required

      (Optional) Require that the assertion issuer and the certificate DN (found within the WS‑Security document) have the same identity.

    • Require Signature over WSU:Timestamp Element

      (Optional) Require validation of any <wsu:Timestamp> and <wsu:TimestampTrace> elements in the message

    • Require Secure Transport Layer

      (Optional) Require all messages to be received over a secure (SSL or TLS) connection.

11. (Optional) For messages with multiple WS‑Security headers, specify the value of the SOAP actor (role) attribute that identifies the header element from which SOA Security Manager should obtain security tokens in the SOAP Role field (located in the Advanced group box). For example:

    http://www.example.com/soap/MySOAPRole
    

12. Click Submit.

    The authentication scheme is saved and may be assigned to application components (realms).