Authentication

Applies to ReadyAPI 3.52, last modified on April 25, 2024

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

  1. 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:

    Service virtualization and API testing: Authentication settings of a virtual service
  2. 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:

    Service virtualization and API testing: Authentication settings in request

Notes

  • If you want a request to fail when it receives the 401 Unauthorized error, 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 Authorization.

See Also

Configuring Virtual Services

Highlight search results