Web Service Security
SOAP-based Web services support the WS-Security standard which describes how security signatures and encryption are attached to headers of SOAP messages for access control. If you have session server security enabled in the Administrative Console, the user name and password credentials (for a user in the User security profile in Administrative Console) can be transmitted in the SOAP headers. If your client does not support WS-Security, inband equivalents are enabled by default, so information is passed in the data payload.
REST services use Host Integrator credentials that are sent using the environment variables in the request message. REST services use HTTPS for security and can be configured to use HTTP basic access authentication, preferably over HTTPS.
Web services automatically start HTTPS on port 9681 using SSL. To configure security features, edit the
HostIntegrator\sesssrvr\services\ws\META-INF\service-cfg.xml file to change the secure, transportLayerSecurity, authnMetadata, or authnService properties.
To enable HTTP Basic Authentication, edit the
%VHI_ROOT%/sesssrvr/services/ws/META-INF/service-cfg.xml file to set authnMetadata and authnService to true. The authnService enables basic authorization for execution, while authnMetadata enables basic authorization for accessing metadata. The credentials are cached by the web service and not passed to the session server until a subsequent SOAP or REST request is received. If the user is unauthorized, the initial HTTP authentication will appear to succeed but the subsequent request will fail.
When Basic Authentication is enabled, you cannot test web services using VHI Web Services Explorer as the SOAP client. Authentication credentials sent via SOAP, REST, or HTTP Basic Authentication are transmitted over the network as clear text unless an HTTPS connection is used.
For more information see Security Overview for Verastream 7.x.
In a default installation of Host Integrator, self-signed security certificates (server.cer) are generated. To add your own certificates issued by a trusted certificate authority (CA), see Using Custom Keystores and Certificates.