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

WebSphere Application Server 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 we 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 we need to 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 WebSphere Application Server 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. We must 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 WebSphere Application Server, before we can use them. The following SAML policy sets exist:

• SAML11 Bearer WSHTTPS default: sends a SAML token using the bearer confirmation method in SOAP messages, and protects SOAP messages using SSL

• SAML11 Bearer WSSecurity default: sends a SAML token using the bearer confirmation method in SOAP messages, and protects SOAP messages using X.509 signing and encryption

• SAML11 HoK Public WSSecurity default: sends a SAML token using the holder-of-key confirmation method with a client X.509 certificate in the SAML token, and protects SOAP messages using the client certificate in the SAML token and the X.509 certificate of the recipient

• SAML11 HoK Symmetric WSSecurity default: sends a SAML token using the holder-of-key confirmation method with a shared key that is encrypted by recipient public key, and protects the SOAP message using the shared key for signing and encryption

• SAML20 Bearer WSHTTPS default

• SAML20 Bearer WSSecurity default

• SAML20 HoK Public WSSecurity default

• SAML20 HoK Symmetric WSSecurity default

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.

• Saml Bearer Client sample

• Saml Bearer Provider sample

• Saml HoK Symmetric Client sample

• Saml HoK Symmetric Provider sample

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

WebSphere Application Server 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 creating 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 we 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 that 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 that specified. If a general binding is found, the binding is used for the trust client request. If no binding with the name that 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.

Related tasks

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