IAM One-Shot end-point configuration

Airlock IAM handles one-shot requests in a different way than redirect requests: The Airlock Gateway sends the one-shot requests to IAM end-point 'login-oneshot' (instead of 'check-login' for redirect workflow).

• The one-shot end-point is configured as follows in IAM:
• Loginapp >> Airlock One-Shot Authentication
• Define the target applications or services to be protected.
• For each target application the following settings are specific for one-shot:
• Credential Extractor: specifies how to extract a credential (e.g. a token, a ticket, or a header containing information about the authenticated user) from the HTTP request.
• Authenticator: specifies how to check whether the credential is valid and thus whether the request is authenticated
• Failure Responses (error mapper): specifies how to respond to the HTTP Client if the request is not authenticated
• All other properties (ID propagator, URL pattern, etc.) are the same as in normal target applications.

The configured elements mentioned above (Credential Extractor, Authenticator, Failure Responses) are used as follows:

1. The credential extractor extracts a credential (authentication information) from the HTTP request. Depending on the credential extractor, you have to choose One-Shot or One-Shot with body in the Airlock Gateway target application/service mapping configuration. In case the credential extraction was not successful, the error mapper (Failure Responses) defines the response that is sent to the client. Otherwise, the workflow continues with the next step.
2. The extracted credential is checked using the configured authenticator. The credential must be compatible with that authenticator. The credential type produced is documented in the extractor plugin and the authenticator plugin usually documents the supported credential types. In case of authentication failures, the configured behavior of the error mapper (Failure Responses) is executed. In case none of the error types match the given authentication failure type, the default authentication behavior is selected and executed. If authentication is successful, the workflow continues with the next step.
3. The roles granted by the authenticator are matched against the required roles (a property on the target application - see group Roles Processing) after applying any role transformation rules.

Access is granted and the workflow proceeds to the next step if at least one of the required roles is granted by the authenticator. Otherwise, the error mapper (Failure Responses) defines how to respond to the client.

4. Eventually, the identity propagator adds identity information (e.g. a JWT header) to the response and the roles using the Airlock Gateway Control-API (CAPI) such that the Gateway can forward the "temporarily stopped" request to the back-end.