ID propagation and authorization Identity propagation and authorization in the JSP-Loginapp
Identity Propagator
Defines the identity propagator to use: it tells Airlock IAM how to propagate the user's identity (and other information) to the target application.
There are many ways to transport user information to target applications. The most important simple ones are:
  • HTTP Basic Authorization (use the "Airlock Basic Auth Identity Propagator")
  • HTTP Headers, e.g. JWT in an Authorization header (use the "Airlock Header Identity Propagator")
  • Cookie with username (use the "Username Cookie Identity Propagator"); this is also used for Kerberos as identity propagation
  • Tickets in Cookies (use the "Cookie Ticket Identity Propagator"; see ID propagation with cookies (JSP-Loginapp))
  • On-behalf form login (use the "On Behalf Login Identity Propagator")
More complicated methods include (only Airlock IAM)
  • SAML 2.0 assertions over HTTP cookies (see "SAML Assertion Cookie Identity Propagator"); see also 14. SAML 2.0 (conceptual information) for full SAML 2.0 support.
  • OAuth 2.0 and Open ID Connect (use the "OAuth 2.0 ..." and "Open ID Connect..:" identity propagators)
Building Block Plugins:
  • Combining Identity Propagator: combines several other identity propagation methods
  • Conditional Identity Propagator: only performs the identity propagation if one or more conditions hold. Often used with the "Combining Identity Propagator"
See description.
Specific Access Policy
Access Policies define a list of rules that are applied after successful login in order to determine additional roles based on Risk Tags and already assigned roles.
This settings overrides the Default Access Policy in the Application Settings in order to provide target-application-specific rules. If not specified, the global policy takes effect (if any).

Username Transformation
Used to transform the username before being propagated to the target application, i.e. before being passed to the identity propagator plugin.
It can be used, for example, to send an internal user identifier to the application while the user logs in using the email address (example).

Required Roles
A list of roles required to access this target application. The user needs one of the roles in order to get access to the application.

If no roles are configured, all authenticated users may access the application.

The user's roles may be transformed before being compared to this list using the Role Transformation Rules (see separate property).
If the user doesn't have any of these roles, the "Step-Up Authenticators" (in Authentication Settings) are consulted in order to find out whether they can be obtained using a Step-Up.

Airlock Credentials
The Airlock roles/credentials that should be set when accessing this target application, instead of using the users roles as Airlock roles/credentials.
The name of the credential can be followed by a colon and the idle timeout of the credential in seconds, e.g. "myrole:300" sets the credential "myrole" that will expire after 5 minutes of client inactivity.
With a second colon and a second number, the life-time can be set, e.g. "myrole:300:3600" will set the credential "myrole" for a maximum of 1 hour, but it will also expire after 5 minutes of client inactivity.
Note: If you want to replace (instead of add) target application's Airlock credentials in the session upon the first visit of each target application, you have to disable the "Add Credentials To Session" flag in the AirlockConfig section.


The following example sends a JSON web token (JWT) with the username and some more information in an Authorization "Bearer" header to the target application "CUSTOMER PORTAL":