Section – Authorization and authentication

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 that precede attacks.
  • In combination with an Airlock API Gateway as a 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 a certificate. 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.

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 the 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 the 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 in 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

Logout propagation can be enabled by setting a Logout propagation path in a mapping. Whenever a gateway session terminates, either due to an explicit logout by the user or due to a session timeout, Airlock Gateway will call the configured path on the currently used back-end host with all information concerning this back-end application, such as cookies, headers, etc. This allows clean session termination on back-end systems when an Airlock Gateway session terminates. 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 some back-end logouts may be delayed or even skipped under heavy load or if there are back-end outages.

Logout propagation host header

A back-end host variable or a static value can be set to add a specific host header to the logout propagation request. This may be necessary if the back-end uses name-based virtual hosts.

  • Examples:
  • back-end.example.com
  • 192.0.2.48

Unlike host headers in normal user requests, the logout propagation host headers cannot be modified on the virtual host or on the mapping by request actions. If the Logout propagation host header field is left empty, the configured back-end hostname in the back-end group is used as the host header.

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.