WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts > SAML conceptsSAML default policy sets and bindings
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
We must import 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 needed 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 security token service, which is a special-purpose web service. We can use any of the default WAS 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. You 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.
SAML20 Bearer WSHTTPS default Send a SAML token using the bearer confirmation method in SOAP messages, and protects SOAP messages using SSL SAML20 Bearer WSSecurity default Send a SAML token using the bearer confirmation method in SOAP messages, and protects SOAP messages using X.509 signing and encryption SAML20 HoK Public WSSecurity default Send 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 SAML20 HoK Symmetric WSSecurity default Send 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 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
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 creating an application-specific binding for a policy set, the binding begins in an unconfigured state. You 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 you 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 you specified. If a general binding is found, the binding is used for the trust client request. If no binding with the name that you 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
SAML holder-of-key symmetric key token
SAML bearer token
Communicate with STS