Security Policy Descriptions
The primary purpose of the wizard is to provide configurable security policies. The choices for Security Policy are as follows:
The following section lists all the policy options.
SSL/TLS Connection Security
This policy requires use of HTTP over SSL/TLS (HTTPS) between the web client and the web service. It provides confidentiality and integrity of the data stream, authentication of the server, and optional authentication of the client.
Username Authentication over SSL/TLS
This policy requires the client to send a <UsernameToken> (with username and password). This policy also requires HTTP over SSL/TLS (HTTPS), which provides confidentiality and integrity of the data stream, authentication of the server, and optional authentication of the client.
At runtime, the web client must create and add the username token with the default password type. See Adding a Username Token.
X.509 Certificate Authentication over SSL/TLS
This policy requires the client to send messages with signed body and timestamp and the X.509 certificate that can verify the signature. WS-Addressing headers, if included, are also signed. This policy also requires HTTP over SSL/TLS (HTTPS), which provides confidentiality and integrity of the data stream, authentication of the server, and optional authentication of the client.
Authentication with Symmetric Keys
This policy requires a single, shared secret key that is used to both sign and encrypt the message. This symmetric key is generated at runtime and is encrypted using the public key of the service’s certificate.
The service can optionally require an encrypted username and password with the default password type for authentication; if you choose this option, the client must add the <UsernameToken> at runtime, as described in Adding a Username Token. It is not necessary to manually encrypt the <UsernameToken>; InterSystems IRIS automatically encrypts it.
Symmetric Keys with Endorsing Certificate
This policy requires a single, shared secret key that is used to both sign and encrypt the message. This symmetric key is generated at runtime and is encrypted using the public key of the service’s certificate.
The service can optionally require an encrypted username and password with the default password type for authentication; if you choose this option, the client must add the <UsernameToken> at runtime, as described in Adding a Username Token. It is not necessary to manually encrypt the <UsernameToken>; InterSystems IRIS automatically encrypts it.
This mechanism uses an endorsing client certificate to augment the token associated with the message signature.
Mutual X.509 Certificates Security
This policy requires all peers to sign the message body and timestamp, as well as WS-Addressing headers, if included. It also optionally encrypts the message body with the public key of the peer's certificate.
The service can optionally require an encrypted username and password with the default password type for authentication; if you choose this option, the client must add the <UsernameToken> at runtime, as described in Adding a Username Token. It is not necessary to manually encrypt the <UsernameToken>; InterSystems IRIS automatically encrypts it.
SAML Authorization over SSL/TLS
This policy requires the client to send a SAML token that contains an X.509 certificate or a public key. The corresponding private key signs the message body and timestamp, as well as WS-Addressing headers, if included. This policy also requires HTTP over SSL/TLS (HTTPS), which provides confidentiality and integrity of the data stream, authentication of the server, and optional authentication of the client.
SAML with X.509 Certificates
This policy requires the client to send a SAML token. This policy also signs the message body and timestamp, as well as WS-Addressing headers, if included. It also optionally encrypts the message body with the public key of the peer's certificate.
