WS-Security Asymmetric Binding Policy
Learn about the WS-Security Asymmetric Binding Policy.
Supported Platforms: 7.2 and later
Table of Contents
- About the WS-Security Asymmetric Binding policy
- Creating a WS-Security Asymmetric Binding policy
- Use case: using a clusterable cache with the WS-Security Asymmetric Binding Policy
About the WS-Security Asymmetric Binding policy
The WS-Security Asymmetric Binding policy provides support for the Asymmetric Binding Assertion. Asymmetric binding is suited for when both parties (client and service) possess security tokens. For example, if both parties possess X.509 certificates, an asymmetric binding is used where the initiator or client uses its private key to sign and the recipient’s public key to encrypt. The Recipient or the Web service uses its private key to decrypt, and the initiator's public key to verify the signature.
Asymmetric binding allows defining tokens used by the initiator and the recipient using Initiator Token and Recipient Token properties. These are properties specific to asymmetric binding.
Creating a WS-Security Asymmetric Binding policy
The first step in creating a policy is to define the basic policy information. Then, you can configure the policy details.
To add an operational policy
- Go to Workbench > Browse > Organization, and select Policies > Operational Policies. The Policies Summary is displayed.
- Click Add Policy.
- Choose the policy type and click Next.
- Specify a name (required) and description (optional) and click Finish. The Add Policy Wizard creates a draft policy instance that you can then configure on the Policy Details page.
For more information, see Add Policy.
Use case: using a clusterable cache with the WS-Security Asymmetric Binding Policy
This section provides an illustration of how to use clusterable caching with the WS-Security Asymmetric Binding Policy.
- Launch the Policy Manager Management Console and create a physical service.
- Virtualize this physical service and host it on Cluster with at least two Network Director (ND) nodes.
- Perform the required steps for setting up a clusterable cache and using in the com.soa.policy.handle.wssp.noncecache and com.soa.grid property as illustrated in Using a Clusterable Cache.
- Assign Detailed Auditing, Consumer Authentication, Enduser Authentication, WS-Security Asymmetric Binding, WS-Security Supporting Tokens and WS-Security Message Policies to virtual service. For specific policy configurations, see below.
Consumer Authentication Policy Configuration:
End-user Authentication Policy Configuration:
WS-Security Asymmetric Binding Policy Configuration:
WS-Security Supporting Tokens Policy Configuration:
WS-Security Message Policy Configuration:
- Assign PKI keys and certificate to the virtual service:
- Assign Detailed Auditing, Consumer Authentication, Enduser Authentication, WS-Security Asymmetric Binding, WS-Security Supporting Token and WS-Security Message Policies to the virtual service.
- Create a project in a client, such as SoapUI, using the virtual service WSDL URL.
- Double-click a project (for example, Echo).
- Navigate to Security Configurations > Keystores/Certificates.
- Click Adds a new crypto to this configuration.
- Assign a valid jks.
- Click Outgoing WS-Security Configurations.
- Click Adds a new Outgoing WSS Configuration.
- Enter unique name.
- Click OK.
- Click Adds a new WSS Entry.
- Select Time stamp and click OK.
- Enter time to live as 300 milliseconds.
- Click Adds a new WSS Entry.
- Select WSS Entry type as Username and click OK.
- Configure Username as shown below.
- Click on Adds a new WSS Entry.
- Select WSS type as Signature and click OK.
- Configure signature as shown below.
- Name: Name space
- Timestamp: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
- Body: http://schemas.xmlsoap.org/soap/envelope/
- Click New WSS Entry.
- Select WSS type as Encryption and click OK.
- Configure Encryption as shown below.
- Save preferences.
- Select test in Outgoing WSS and send a request to the virtual service.
The request is processed successfully. You can see the recorded message tab, as shown below.
- Verify that the wsse:Nonce header passed through the request. Similarly, view any continuous requests and make sure that the tokens are unique for various Network Director nodes.