Set Transport Security
This task describes how to set transport security for your virtual service.
Note:
- This task is part of a higher-level task. For details, see Set Security.
- To learn more about Service Virtualization security, see Virtual service security.
Transport level security is completely handled by the HTTP based agent. The virtual and real services can use HTTP authentication to prevent unauthorized use. The service can use basic, digest, NTLM authentication, or Mutual HTTPS.
Services secured with HTTPS are supported by either the HTTPS Gateway agent or the HTTP(S) Proxy agent. Both agent types also support Mutual HTTPS where the client authenticates itself with a client certificate. To use Mutual HTTPS, the credential store must contain a client certificate and its private key for every client accessing the virtual service. For details on setting authentication credentials, see Edit Credential Store Dialog Box
The mutual HTTPS authentication for the HTTPS Gateway agent is handled by the client operating system. Therefore, the certificate of the certification authority that issued all client certificates in use must be imported into the local computers’s Trusted Root Certificate Authorities store.
To import the Certification Authority's certificate into the local system's certificate store:
- From the command line or Windows Start menu Search bar, type
mmc
to run Microsoft Management Console. - From the File menu, select Add/Remove Snap-in.
- From the Available Snap-ins list, select Certificates and click Add. In the screens that follow, select Computer account, and then Local Computer. Click Finish.
- To import the certificates, expand the Certificates (Local Computer) node, as shown below. Under Trusted Root Certification Authorities, right-click Certificates and select All Tasks > Import.
-
Follow the on-screen directions to import the certificates.
When using a proxy agent and running the virtual service in Stand-By or Learning mode, the authentication is fully transparent and the virtual service does not need any further configuration. The entire security handshake is passed from the client to the real service through the proxy, and client credentials are validated just by the real service.
HTTP authentication is not used when the service is in Simulating mode.
When using the gateway agent and running the virtual service in Stand-By or Learning mode, the client authenticates to the virtual service and the virtual service authenticates to the real service. The virtual service must be able to validate a client’s credentials and pass them to the real service, meaning that the service must have all user names and passwords in the credential store.
There are several steps to set this authentication:
-
All users who are authenticating to your service must be present in the Windows system where the virtual service is running. They can be added as local users of the machine or added to the domain to which the computer belongs. The username and password must be the same as the one the client uses to authenticate to the real service.
-
To delegate requests to the real service (when learning or in stand-by mode), the username and password must be in the service's credential store.
- In the Virtual Service Editor, expand Security Settings and click Edit Credential Store.
- Click Add Identity.
- Enter Identity details and supply a certificate if required.
- Click OK to add the identity and OK again to close the Credential Store.
Note: HTTP digest authentication only works with domain users, not local ones. The domain must have reversibly encrypted passwords. See IIS documentation for details.
Note: When using HTTP Basic authentication, credentials missing in the credential store are automatically detected and can be simply added via the Fix It command in the Problem List.
HTTP authentication is not used when the service is in simulating mode.
Basic, digest and NTLM authentication in the HTTP / HTTPS Gateway agent is supported only with Windows accounts:
-
If the computer running Service Virtualization is in the same domain as the service host, make sure the domain users are able to log on to the machine the application is running on. Clients authenticated on the real service must be able to authenticate on the machine running the virtual service.
-
If machines cannot be placed in the same domain, create local windows or domain user accounts (domain users still need to be able to log on the machine the application is running on) with the same names that the client is using to authenticate to the service.
Note: If you would like to use the HTTP Digest authentication, use only domain user accounts as local user accounts will not authenticate.