Section – Authorization and authentication

Preceding authentication with Airlock Gateway implements centralized access control that is completely decoupled from the underlying application.

Only authenticated and authorized connections can access the application – Airlock Gateway thus resolves the problem of anonymous connection attempts which precede attacks.
In combination of anAirlock API Gateway as policy enforcement point and an Airlock IAM to manage client information, control and rate-limiting for Tech-Clients can be configured with restrictions to roles and plans.

SSL client certificate

Specifies whether accessing this mapping requires the client to authenticate with a valid SSL client certificate. Together with the SSL Server certificate, client certificates provide mutual authentication between Airlock Gateway and the browser. If the client authenticates himself with a client certificate, any man-in-the-middle attack is prevented.

Options:
Inherit from virtual host: The mapping uses the client certificate settings of the virtual host.
Optional: The client may send a certificate if available, but access is still allowed without. The optional setting is normally used in combination with an authentication service that presents an alternative login page if no certificate is sent. You should not use the 'optional' setting without this additional authentication service check.
Required: The client must send a valid certificate. If no client certificate is sent, the SSL handshake is canceled and the browser typically presents the user with a technical error message.

If possible, configure this setting on the Virtual Host since having different settings between the Virtual Host and its mappings can lead to problems with renegotiation. For details please refer to the following techzone article.

This setting is also available for each virtual host. If you need to check client certificates, it is recommended to require a client certificate on the virtual host level, not on the mapping level. If client certificates are required on the virtual host, the connected mappings can be set to "SSL client certificate: inherit from virtual host".

It is only possible to override the virtual host settings with stronger mapping specific settings. I.e. use "optional" on virtual host and "required" on the mapping, but not the other way round.

Access restrictions

A list of access restrictions can be created. Each request matching the combination of HTTP method and path of an access restriction must have at least one of the specified roles to access the service. All matching restrictions must be satisfied to gain access.

If the restriction list is empty or no restriction matches, access is granted. For example, if a restriction only matches HTTP GET requests, POST or PATCH requests on the same URL must be covered by separate restriction rules. Otherwise, they will be allowed.

Column name	Description
HTTP Method	This field can contain a regular expression. Role and plan restrictions are applied if the HTTP method of a request matches the expression. Use an empty pattern if all HTTP methods should match. Example: ^(POST\|PUT)$
Path	This field can contain a regular expression. Role and plan restrictions are applied if the HTTP method of a request matches the expression. Use an empty pattern if all paths should match. Example: ^%ENTRYDIR%/administration/?
Restricted to Roles	This field can contain a list of comma-separated roles for this service. Only sessions that have at least one of these roles (e.g. admin, sales, crm) will be able to access the service. Example – Restricted to roles
Restricted to Plans	This field can contain a list of comma-separated plans. Plans restrict the access of Tech-Clients (identified by API keys). Only clients who have at least one of these plans will be able to access the service. Example - Restricted to plans

Authentication flow

Drop-down entry	Description
Redirect (default)	If the required role for the mapping is missing on the current session, Airlock Gateway will send a redirect (HTTP 303) to either the global or the custom denied access URL. This mode is typically used in conjunction with user operated clients.
Deny access	Airlock Gateway will directly send an access denied (HTTP 403) response to the client if the required role is missing. This is typically used for technical clients.
One-shot	When this option is selected and Airlock Gateway receives an incoming request for this mapping that needs to be authenticated, Airlock Gateway implicitly (without redirect) forwards the request to the configured denied access URL for this mapping. The request headers are forwarded but no request body. After the forwarded request, Airlock Gateway checks again if the session is now authenticated. If so, the original request is passed to the back-end server (successful one-shot authentication). If the session does not have the required credentials even after the one-shot request, Airlock Gateway will send an access denied (HTTP 403) response to the client.
One-shot with body	This is the same as with the "one-shot" option with two notable differences: The whole body of the request is also sent to the denied access URL for this mapping and the request method is always POST instead of GET.
Front-side NTLM	Choose the front-side NTLM authentication flow to support authentication using NTLM. The front-side NTLM authentication flow is similar to the "one-shot" authentication flow, but also forwards all requests containing an "Authorization" header with value "NTLM .*" to the denied access URL. For successful authentication, NTLM must be supported by the authentication service.

Denied access URL

Defines the location of the authentication service. In case the required role for the mapping is missing on the current session, Airlock Gateway will redirect the client to this location.

Use Global (default) will use the global denied access URL as configured under the menu Use Global.
Custom will use a mapping specific denied access URL.

Logout propagation path

In order to allow clean session termination on back-end systems when an Airlock Gateway session terminates, the administrator can configure one logout path per mapping. Whenever an Airlock Gateway session terminates (either due to an explicit logout by the user or due to a session timeout), Airlock Gateway will call the given, unmodified path on the currently used back-end host with all information concerning this back-end application such as cookies, headers, etc. The path is called "as is", without any rewriting.

Example: /myaccount/logout.do

The back-end logout propagation is a best-effort service. This means that it may happen that some back-end logouts may be delayed or even skipped under heavy load or if there are back-end outages.

Custom error page for deny access and one-shot

By default, the error page with the HTTP response status code 403 is used. Airlock Gateway allows to return a custom response document with the expert settings Authentication.DenyAccess.ErrorPath (deny access authentication flow) and Authentication.Implicit.ErrorPath (one-shot authentication flows) on the Expert Settings - Security Gate page.

The custom error page must be uploaded with the Configuration Center as described in Submenu – Error Pages. The error page must be in the as-is format and use the file extension ".asis". With the as-is format, it's possible to specify the HTTP response status code (e.g. 401 or 403) and additional HTTP response headers.