IAM configuration for bank API calls 

In order to verify the bank API calls (e.g. /payments, /accounts/, etc.) the following configuration steps are necessary. See linked separate detail pages where necessary. All OAuth-related settings are described separately further below.

Please refer to HTTP request authentication (Airlock One-Shot flow) for general information on "one-shot" configuration.

  1. Create a new "Target Application/Service" in Loginapp >> Airlock One-Shot Authentication

    2. Within the target application, proceed as follows.

  2. Configure the „Credential Extractor“:  HTTP request signature verification for STET
  3. Setup HTTP Request Authentication: TPP Authentication using client certificates and OAuth 2.0 for STET
  4. Define STET-compliant error responses (HTTP status code in failure cases):
    1. For property "Failure Responses" use the Plugin "Configurable Error Mapper" 
    2. Use a "Failure HTTP Response" with the following values for properties "Default Authentication Failure Response", "Authorization Failure Response (user has no access)", and "Credential Extraction Failure Response":
      1. HTTP Status Code: 400
      2. Workflow: FINAL_RESPONSE
  5. Setup Identity Propagation:
    1. "Identity Propagation" is used to inform the bank's API service about who the TPP is. Any IAM or custom "Identity Propagator" that allows attaching information to an HTTP request (using the Airlock Gateway (WAF)'s control API) may be used.
    2. The TPP's "organizationIdentifier" is available as "username" in the Identity Propagator plugins
    3. The granted OAuth 2.0 scopes are available as user roles in the Identity Propagator plugins
    4. We recommend sending a JWT in an HTTP header to the bank's API service. This would involve the following plugins:
      1. "HTTP Header Identity Propagator" as Identity Propagator; use an "Encoded User Data Header" plugin to add a JWT
      2. "Mapping Ticket Service" to put together the information in the JWT (use "@username" and "@roles" as value reference)
      3. "JWT Ticket Encoder" to define how to assemble and cryptographically protect the JWT
  6. Disable the "User Trail Log": if left enabled, a user trail log entry is written for every bank API request. This might "flood" the user trail log and prevent important user trail log entries from being available.
  7. Choose an URL pattern: Since the TPP roles are checked on the Airlock Gateway (WAF), there is normally no need to add a separate "Target Application/Service" for each bank API call.
    1. Choose an URL pattern that matches all bank API calls (e.g. https://api.bank.example.com/v1/.*)
    2. If it is the default "Target Application/Service" the URL pattern is ignored
    3. If you wish to use different settings for single bank APIs (e.g. some identity propagation settings for "/payments" and others for "/accounts"), create multiple "Target Application/Service" plugins and choose the corresponding URL patterns.