Supported Web Service Security Standards

The following security policies, in the form of XML files, are provided for Web service clients.

Note: The transport level security policies (http basic and https basic) can be applied to a SOAP Web service, but they do not prevent an anonymous user from invoking the Web service. When using the basic security policies or when creating a custom security policy, consider this security issue.

Transport or Standard	System Security Policy	Description
HTTP	Http-Basic-Authentication.xml	Policy that requires a username and password when making a request.
HTTP	Http-Negotiate-Authentication.xml	Policy that enables Kerberos authentication.
HTTP	Http-NTLM-Authentication.xml	Policy that enables NTLM authentication.
HTTP	Http-UsernameToken-Digest.xml	Policy that validates against a UsernameToken header encrypted using a nonce value.
HTTP	Http-UsernameToken-Plain.xml	Policy that validates against a UsernameToken header. The password can be in plain text.
HTTPS	Https-Basic-Authentication.xml	Policy that requires a username and password when making a request.
HTTPS	Https-ClientCertificateRequire.xml	Policy that requires client certificates.
HTTPS	Https-UsernameToken-Digest.xml	Policy that validates against a UsernameToken header encrypted using a nonce value.
HTTPS	Https-UsernameToken-Plain.xml	Policy that validates against a UsernameToken header. The password can be in plain text.
SAML	Saml1.1-Bearer-Wss1.1.xml	Method in which the bearer assertion is used to facilitate single sign-on to the web browser.
SAML	Saml1.1-HolderOfKey-Wss1.0.xml	Method that establishes a correspondence between a SOAP message and the SAML assertions added to the SOAP message.
SAML	Saml1.1-SenderVouches-Wss1.1.xml	Subject-confirmation method that enables an attesting entity to vouch for the identity of a subject to a party that trusts the sender.

The following legacy WSS standards are supported:

•

OASIS Web Services Security: SOAP Message Security 1.0 Standard 200401, March 2004

•

Username Token profile V1.0

•

X.509 Token Profile V1.0

The TDV Server accepts certificate formats such as X.509 and JKS so that keys and message signatures do not need to be converted to ASCII before sending.

The TDV pipeline implementation allows SAML and Kerberos tokens to be passed through to message destinations, but TDV Server does not directly process or use SAML and Kerberos tokens.

WSS incorporates security features in the header of a SOAP message, and works in the application layer to help ensure end-to-end security for SOAP messages.

WSS UsernameToken SOAP header validation is independent of the message-security pipeline; the message security pipeline cannot process these contents.

Transport Layer Security (TLS) is supported to ensure message integrity and confidentiality through HTTPS, reducing performance overhead. If the messaging needs to pass through a proxy server, however, TLS should not be used without special handling considerations.

Top