Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure web services > Web Services Security concepts > SAML concepts


Default policy sets and sample bindings for SAML

SAML-specific default policy sets and general bindings are provided when the SAML function is installed. These policy sets and sample general bindings are used to request SAML tokens from an external Security Token Service (STS), and to propagate SAML tokens to downstream web services.


SAML default policy sets

WAS with SAML provides eight default policy sets and several sample general bindings that support the OASIS Web Services Security SAML Token Profile 1.1 standard. We must import the SAML default policy sets before you can use them. We can attach these SAML policy sets and sample bindings to web services and begin using SAML capability without writing any additional code. However, there are a few configuration parameters that set in the sample bindings documents before using them. These parameters include the external STS URL, and the SAML token issuer X.509 certificate. For more information, read about configuring client and provider bindings for the SAML bearer token and configuring client and provider bindings for the SAML holder-of-key (HoK) symmetric key token.

The SAML function installation includes the Username WSHTTPS default application policy set, which sends a trust request to an external STS. A Security Token Service (STS) is a special-purpose web service. We can use any of the default WAS Version 7.0 and later policy sets to communicate with the STS. However, the Username WSHTTPS default policy set sends a Username token in the SOAP message, and protects the message using SSL. Configure a user name and password in the bindings document to use this policy set. For step-by-step instructions, read about configuring policy sets and bindings to communicate with STS.

Four SAML 1.1 default policy sets and four SAML 2.0 policy sets are provided as part of the SAML function installation. As described in the topic, Setting up the SAML configuration, add these policy sets to an existing profile, or create a new profile after installing WAS, before you can use them. The following SAML policy sets exist:

The only difference between the SAML 1.1 policy sets and SAML 2.0 policy sets is the SAML token namespace.


SAML sample bindings

Two pairs of sample bindings are provided to support the SAML bearer token and the SAML holder-of-key token that uses a symmetric key.

We can use the Saml Bearer Client sample and the Saml Bearer Provider sample with any of the SAML bearer token default policy sets. We can use the Saml HoK Symmetric Client sample and the Saml HoK Symmetric Provider sample with one of the SAML HoK Symmetric key default policy sets: either SAML11 HoK Symmetric WSSecurity default or SAML20 HoK Symmetric WSSecurity default.


Trust client bindings

WAS with SAML supports both application-specific bindings and general bindings for trust client.policy sets. In addition, default bindings are supported if the application is running in a server environment. Default bindings are not supported in the thin client environment.

We can create application-specific bindings only at a policy set attachment point. These bindings are specific to and defined by the characteristics of the policy. Application-specific bindings can provide configuration for advanced policy requirements, such as multiple signatures; however, these bindings are only reusable within an application. Furthermore, application-specific bindings have limited reuse across policy sets. When you create an application-specific binding for a policy set, the binding begins in an unconfigured state. We must add each policy, such as WS-Security or HTTP transport, to override the default binding, and fully configure the bindings for each policy that we have added. For more information about configuring trust client bindings for SAML, refer to configuring policy sets and bindings to communicate with STS.

General bindings can be configured for use across a range of policy sets and can be reused across applications and for trust service attachment points. Although general bindings are highly reusable, they do not provide configuration for advanced policy requirements, such as multiple signatures. There are two types of general bindings: general provider policy set bindings, and general client.policy set bindings.

If you do not specify the wstrustClientBindingScope property for the trust client binding, the system searches first in the application for an application-specific binding with the binding name specified. If a binding is found, the binding is used for the trust client request. If no application-specific binding is found, the system searches the available general bindings for a binding with the name specified. If a general binding is found, the binding is used for the trust client request. If no binding with the name specified is found, then default bindings from the server environment are used. The default bindings are used only when the application is running in the server environment. If the application is running in a thin client environment, and no wstrustClientBindingScope property is specified, and no application-specific or general bindings are found, then no bindings are used because default bindings are not supported for a thin client.
Configure client and provider bindings for the SAML holder-of-key symmetric key token
Configure client and provider bindings for the SAML bearer token
Configure policy sets and bindings to communicate with STS

+

Search Tips   |   Advanced Search