On the Auth page of the virtual service editor, you can configure authentication settings for your service.
How It Works
In the real world, authentication protocols use custom headers and special procedures to set up connection between servers and clients. In ReadyAPI, virtual services do not emulate these complex scenarios. When a virtual service receives a request, it simply checks if this request contains the
Authorization header starting with a value that matches the authentication type you chose on the Auth page.
If the request contains the
Authorization header and that header starts with the appropriate string, then the service processes the request according to the dispatch or behavior settings.
If the request does not contain the
Authorization header with the appropriate string, the service returns the
401 Unauthorized error and does not process any other responses (it ignores the Errors behavior settings, for example).
Configuring Virtual Service Authentication
On the Auth page of the virtual service editor, select the desired authentication type.
The editor will display the Header and Starts with edit boxes.
Remember these values or copy them to the clipboard:
Insert the copied header to the requests you will send to the virtual service.
If you are going to use ReadyAPI to simulate requests, simply add the Authorization header as a custom header to the requests:
If you want a request to fail when it receives the
401 Unauthorizederror, you need to add an assertion to your request. By default, when the virtual service returns this error, the test case execution does not fail.
If authorization fails, virtual services do not process the incoming requests. This means, for example, that the Errors behavior settings of your service will be ignored.
Real web services that use the SPNEGO/Kerberos authentication type often skip authentication, if requests are coming from localhost. That is why we do not recommend using localhost in URLs of requests that you will send to your virtual service using the SPNEGO/Kerberos authentication. Use a Service Principal Name (SPN) instead (the server name in the simplest case, or the IP address).
For Custom authentication, you can select both the header name and value. For other authentication types, the header is always