Security Tokens

The Security Token Service issues, renews, cancels, and validates security tokens that can contain an identifier for either the WSC or the actual end user. It also allows you to write a proprietary token providers using the included service provider interfaces (SPI). Finally, it provides application programming interfaces (API), based on the WS-Trust protocol, that allow applications to access the service. By default, the Security Token Service serves tokens based on the Liberty Alliance Project and WS-Trust specifications. The WS-I BSP specifications and the Liberty Alliance Project developed security profiles for web services security. These security mechanism are implemented for web services security using the provider interfaces. The following list contains the supported mechanisms.

Anonymous

Carries no security information.

User Name Token

Carries basic information (username and, optionally, a password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.

User Name Token-Plain

Carries basic information (username and a clear text password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.

Kerberos Token

Carries basic information (username and, optionally, a password or shared secret), in a Kerberos token, for purposes of authenticating the user identity to the WSP.

X.509 Token

Contains an X.509 formatted certificate for authentication using credentials created with a public key infrastructure (PKI). In this case, the WSC and WSP must trust each other's public keys or share a common, trusted certificate authority.

SAML-Holder-Of-Key Token

Uses the SAML holder-of-key confirmation method whereby the WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload. Can use either SAML v1.x or SAML v2.

SAML-SenderVouches Token

Uses the SAML sender-vouches confirmation method whereby the WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. Can use either SAML v1.x or SAML v2.