A policy set is WebSphere's reusable bundle of Web Services policies (WS-Security, WS-Addressing, WS-ReliableMessaging, HTTP transport, SSL transport) that you attach to a web service client or provider instead of coding the security by hand. For SOAP calls from BAW:
- The policy set describes what is required: e.g. "Username token in the SOAP header", "sign the body with X.509", "encrypt the body", "use HTTPS".
- A policy set binding holds the how for one server: the actual user / password, the keystore and certificate aliases, the token generator / consumer settings.
- In Process Designer you reference them in the Web service integration: the Security section of a web service integration (or of the Server definition of type "Web service") lets you pick a policy set and its binding that exist in the cell (Services > Policy sets > Application policy sets, and General client policy set bindings).
# typical cell setup for a client calling a partner with a Username token over SSL
Admin console > Services > Policy sets > Application policy sets > New: "PartnerUsernameToken"
add policy WS-Security: Main policy > Request token policies > Username token; add policy SSL transport
Admin console > Services > Policy sets > General client policy set bindings > New: "PartnerBinding"
WS-Security > Authentication and protection > token generator (Username token) > Callback handler > Basic authentication: user = partneruser, password = ...
Process Designer > Process App Settings > Servers > web service server > Security: policy set "PartnerUsernameToken", binding "PartnerBinding"
The BAW-specific rule: the policy set and binding must exist on every Process Server cell where the app is installed (export them from the console: Export policy set, import on the other cell), and their names must match what the process app references. For plain HTTPS + basic auth you do not need a policy set at all: the Server definition's user / password is sent as HTTP basic authentication.
References