The term identity propagation is used to summarize various methods of how Airlock IAM can provide information about an authenticated user to a target application. Identity propagation is highly flexible so that identity information can be propagated to the target application in a format suitable for the target application.
What information about a user is propagated on identity propagation and how this information is structured and encoded depends on the target application that receives this information. Identity propagation is therefore configured directly on the target application.
The user's identity is the obvious piece of information sent to a target application, so the application knows who it is dealing with. However, target applications require different additional useful pieces of information. The following table shows the most important identity propagation attributes available in IAM.
Attribute | Description |
|---|---|
User ID (also referred to as username) | An identifier used by the target application to uniquely identify the authenticated user. The user ID does not necessarily have to be the same for all target applications. The user ID does not necessarily have to be equal to what the user entered in the login form. |
Provided username | The string the end-user entered in the login form (e.g. username, contract number, email address). |
Representer user ID | In case the authenticated user is being represented by a representer, this attribute specifies who is representing the user. |
Roles | Roles granted to the user during authentication. |
Context data | Context data attributes of the user (e.g. postal address or email address). The attributes may be from the user database, another identity provider (OAuth, OIDC), or extracted from an SSO ticket. Propagating context data may be an alternative to synchronizing user data repositories in some scenarios. |
OAuth tokens | Access and ID tokens from OAuth/OIDC flows. |
Login statistics | Login-related statistical information such as latest login dates, number of failed logins, etc. |
Password | In some special cases (e.g. HTTP Basic Authorization), the user's password is required for identity propagation. It is only available if explicitly configured to be available. |
Whether an identity propagation attribute is available for propagation or not depends on the capabilities of the identity propagator plugin and the Loginapp type (Loginapp REST UI or JSP-Loginapp).
Please read the identity propagator plugin's documentation in the Config Editor for detailed information.
To transport identity attributes to target applications, the attributes must be encoded and usually also protected in some way. Airlock IAM supports various encoding schemes providing different levels of security.
If possible, we recommend using JWT (JSON web token) encoding: it is a widespread standard supported by most target application frameworks and it offers proven security features.
Protecting propagated identity information is crucial for the overall security of the system. The receiving target application must be able to verify that the sender of the information (in our case Airlock IAM) is trusted. Propagated identity information must - in general - therefore be digitally signed.
If the propagated information is confidential, the identity information must additionally be encrypted.
Failing to adequately protect the propagated information may result in severe security flaws.
Some identity propagator types (e.g. OAuth and SAML) already specify how the information is encoded and protected. In these cases, the configuration does not offer the choice of encoding.
There are many ways to transport user identity information from Airlock IAM to the target applications. The following table lists ways supported by the product. More transport types can be implemented by providing custom identity propagator plugins.
Transport type | Description |
|---|---|
HTTP Cookie | Identity information is stored in an HTTP cookie and sent to the Airlock Gateway (WAF) cookie store. The cookie is added to all subsequent requests in the corresponding session and sent to the target application. Note that with the default gateway settings, the cookie is never sent to the browser (or any other HTTP client), but is stored in the gateway's session memory. Therefore, the default cookie settings of the gateway provide a high level of security. |
HTTP Header | Identity information is sent to the Airlock Gateway (WAF) in such a way that the gateway adds an HTTP header to all subsequent target application requests in the corresponding session. Note that the header is never sent to the browser (or other HTTP client) but stored in the gateway's session store. It, therefore, provides a high level of security. Identity information can also be sent directly to the browser (or other HTTP client) in an HTTP header. |
URL parameter (SSO ticket) | Identity information is sent to the browser (or other HTTP client) as a URL parameter of an HTTP redirect. The identity information is sent via the client and therefore needs to be protected adequately. This method can be used to transport identity information to arbitrary target applications even if they are not protected by Airlock or if they are in a different protection domain. |
OAuth 2.0 / OIDC | Identity information is transported to target applications by using the standard OAuth 2.0 or OpenID Connect (OIDC) protocols. |
SAML 2.0 | Identity information is transported to target applications by using the standard SAML 2.0 web profiles. |
HTTP Basic Auth | Log in the user on target applications by sending the HTTP Basic Authorization header. User information is sent to the Airlock Gateway (WAF) in a way that the header is sent in subsequent requests on the same session to the target application. Note that this requires the user's password to be available during identity propagation. This method may be used for legacy systems if no better alternative method is available. |
Kerberos | Send the username and roles to the target application using the back-side Kerberos feature of the Airlock Gateway (WAF). |
NTLM | Send the username and roles to the target application using the back-side NTLM feature of the Airlock Gateway (WAF). This feature is deprecated and is neither available in the Loginapp REST UI nor in the Loginapp REST API. If will be removed with IAM 8.0. |