Security Policies

Prior to deploying a web service, you must decide how you want the service to be secured. The following are all supported security policies:

This mechanism protects messages with mutual certificates for integrity and confidentiality, as well as with a Sender Vouchers SAML token for authorization.

When using this security policy, the SOAP client provides an SAML Subject (within an SAML Assertion) containing the name identifier, which signifies the username the server should run the request as. In this case the message payload is signed and encrypted, because the client and server have established a trust relationship using the contents of their respective keystores and truststores.

In this situation, the server only verifies that the supplied username is valid prior to handling the request.

This policy requires that the client have both a keystore and truststore corresponding to the server’s. In addition, Java clients require a callback handler that provides the SAML Assertion containing the username that the server should trust.

It is extremely important to understand that when using this mechanism the client is “vouching” for the username associated with the SOAP request. The SOAP client is, in essence, impersonating a given user or users without being required to supply corresponding passwords. This mechanism is really only appropriate for an SSO (Single Sign On) type scenario, in which you are certain that the client application has appropriately authenticated the users, and you are willing to extend trust to that client using certificate exchange in the keystore and truststore configuration.

The username authentication with symmetric keys mechanism protects SOAP interactions for both integrity and confidentiality. Symmetric key cryptography relies on a single, shared secret key that is used to both sign and encrypt a message. Symmetric keys are usually faster than public key cryptography.

For this mechanism the client does not possess any certificate or key of its own, but instead sends its username and password for authentication. The client and the server share a secret key. This shared, symmetric key is generated at runtime and encrypted using the service’s certificate. The client must specify the alias in the truststore by identifying the server’s certificate alias.

In this situation, the server authenticates the given username using the corresponding supplied password.

This policy requires that the client have a truststore corresponding to the server’s configuration. In addition, Java clients require callback handlers to provide the username and password to send along with the request for the server to validate. For an example of this mechanism, see Username Authentication with Symmetric Keys Example.

This security policy uses SSL (https) for confidentiality and an X.509 certificate to authenticate the user. The user’s certificate must be trusted by the server, and the username that is validated with Windchill is extracted from the certificate. By default, the username is extracted from the subject of the certificate (stripping any preceding CN= from the participant). Since the basic mapping of the certificate to a Windchill username may be insufficient, the logic used to extract the username is configurable. You can implement the com.ptc.jws.security.SubjectToUidHandler interface and configure your servlet implementation using the following:

which specifies your implementation.

<ServletName> within the property name refers to the servlet for which the SubjectToUidHandler implementation should be used.

When writing a Java client to a service protected by SSL, you must supply the https URL of the WSDL for your service to the javax.xml.ws.Service constructor argument as an instance of java.net.URL. Your HTTP server’s SSL certificate must either be signed by a certificate authority or manually imported into the client’s <JAVA_HOME>/jre/lib/security/jssecacerts certificate store.