Security features

Encrypted parameters

Mock.qa offers an encryption feature for users who need to store sensitive data in the config file. This feature uses the RSA cryptographic algorithm to generate a pair of private and public keys for each GitHub account. The private key is stored on the mock.qa server and is never exposed outside of a secure perimeter. The public key is in use by the Encrypt a string dialog in the Tools menu.

Note: The encrypted string should be enclosed in parentheses

Example of an encrypted string usage:

calls:
- method: greet.Greeter/SayHello
  credentials:
  - type: basic-auth
    user: joe
    password: "$RSA2048:rldEHit9cK7kvhAMPBJBU+YloFipXa8Hnr30S0b8Lgbsdd54NWzyo4k0nCLeSWqsW4U7LJXSTrVjGs0VmmA1l7QFadOIHsqYU8mUToIREq9y8xfSo8M7dzSsbYuqTKUiz5oDWEufzzvy0fNGsUHgdw+pQyaePPMPkYHJE8y31JR61atLM8LorEGmKCAuy/YUEF2UHfNXIQjebncZbbSpe1P1KZ5z5l7UwJhgFVEhMO7WpWTqpHoL8kWYT0FotYtQQXAGLzTys1XEcxlrI4rWtnEZwKSx9ifC1PpIVXp7hgVpZ8BjffVyLtc6V1bkoBfaSEWUFPLX/GWhBWXLFL5zwQ=="

Channel and method credentials

Credentials are a set of information that is used to verify the identity of a user or system. This can include a username and password, a digital certificate, or other forms of identification.

If the credentials are valid, the server will allow the request to proceed. If the credentials are invalid, the server will return gRPC 16 Unauthenticated or HTTP 401 Unauthorized response to the client.

The call credentials section does not overwrite the channel credentials but rather supplements them if any channel credentials have already been specified.

IP white list

IP white list credentials allow specifying a list of IP addresses that are allowed to access the whole service at a channel level or a specific method. This can be useful for preventing unauthorized access or for an additional routing of requests based on a requester address.

Definition:

  - type: ip-white-list
    allowedIps: <sequence>

Examples:

  credentials:
  - type: ip-white-list
    allowedIps:
    - 192.188.53.0/24  # CIDR notation is supported
    - 190.152.123.*    # wildcards are supported
    - "$RSA2048:...."  # encrypted strings are supported
    - 81.214.123.123

Basic auth

HTTP basic authentication works by sending a request to the server with a username and password, which are encoded using base64 encoding and included in an "Authorization" header in the request.

Definition:

  - type: basic-auth
    user: <string>
    password: <string>

Examples:

  credentials:
  - type: basic-auth
    user: joe
    password: "$RSA2048:rldEHit9cK7kvhAMPBJBU+YloFipXa8Hnr30S0b8Lgbsdd54NWzyo4k0nCLeSWqsW4U7LJXSTrVjGs0VmmA1l7QFadOIHsqYU8mUToIREq9y8xfSo8M7dzSsbYuqTKUiz5oDWEufzzvy0fNGsUHgdw+pQyaePPMPkYHJE8y31JR61atLM8LorEGmKCAuy/YUEF2UHfNXIQjebncZbbSpe1P1KZ5z5l7UwJhgFVEhMO7WpWTqpHoL8kWYT0FotYtQQXAGLzTys1XEcxlrI4rWtnEZwKSx9ifC1PpIVXp7hgVpZ8BjffVyLtc6V1bkoBfaSEWUFPLX/GWhBWXLFL5zwQ=="

JWT bearer

JSON Web Token (JWT) bearer authentication is a method of authenticating a user or system by sending a JWT in the "Authorization" header of an HTTP request. Mock.qa verifies the token using provided authority endpoint. If the token is valid, mock.qa validates provided token's audience and claims.

Definition:

  - type: jwt-bearer
    authority: <string>
    audience: <string> # optional
    claims: <string> # optional

Examples:

  credentials:
  - type: jwt-bearer
    authority: https://accounts.google.com/.well-known/openid-configuration 

  credentials:
  - type: jwt-bearer
    authority: https://login.microsoftonline.com/<TENANT>/v2.0/.well-known/openid-configuration?appid=<APP-ID>
    claims: app_user, reader

Useful links:

• https://jwt.io/

Client certificate

Client certificate authentication is a method of authenticating a client by using a digital certificate.

There are two different options for how mock.qa validates a client certificate:

• trustedRootCertificateFiles - a client certificate considered to be valid if it is signed by a provided root certificate. This option matches all valid certificates issued by a root certificate. Note that all certificates in a certification path should be provided - all intermediate and root one.
• clientCertificateThumbprints - a client certificate considered to be valid if its thumbprint matches a provided one. This option matches only one certificate at once.

Definition:

  - type: client-certificate
    clientCertificateThumbprints: <sequence> # optional
    trustedRootCertificateFiles: <sequence> # optional

Examples:

  credentials:
  - type: client-certificate
    trustedRootCertificateFiles:
      - /client.intermediate.pem
      - /client.root.pem

  credentials:
  - type: client-certificate
    clientCertificateThumbprints:
      - e2d76ab6e3aadede3772daaca5d757f72cb2ff6a