Configuration

Each target application may have its own identity propagator or even several of them. This section describes the Ticket Cookie Propagator which creates a ticket string encoded in a cookie. This is a very easy and safe way to implement identity propagation and single sign-on (SSO) for applications sharing the same Airlock Gateway (WAF) session.

The Airlock Gateway (WAF) configuration must ensure that the cookie is not sent to the client (e.g. browser) but only transported to the intended target application(s).

Sending the cookie via the client to the target application may result in a severe security vulnerability!

With the default Airlock Gateway (WAF) cookie settings, cookies are not sent to the client, i.e. it is safe with respect to identity propagation. 

Cookie ticket propagator

The following screenshot shows a single propagator attached to the default application.

Adjust the following values for a specific environment:

  • Cookie Name
  • Cookie Path
  • Cookie Domain

The screenshot shows the most common Ticket Service and Ticket Encoder.

Ticket service

The ticket service plugin (here the "Mapping Ticket Service" defines what information is to be propagated to the application.

The shown sample setup includes the following elements:

  • username
  • the display language
  • the internal session ID (GSID) 
  • the authentication method used for login.
61728881.png

Each single element is added using a "Mapped Ticket Element" (or "Regex Ticket Element": allows to modify the values using regular expressions).

Note that user data (username, user roles, email, etc.) are added using the "Content" property.

Other information such as the "display language" and the "GSID" are added using the "Additional Content" property.

Example configuration for the internal session ID:

45393237.png

The following values have to be set for the aforementioned four properties where the ticket key can be freely configured and the Value Ref must be configured exactly as shown below (case sensitive):

What

Name in Ticket

Referenced by

Referenced where

The username

username

@username

Content

Authentication method attribute of user context data container

authmethod

auth_method

Content

Internal session ID (stable across the whole user session)

gsid

GSID

Additional Content

Language the login pages were viewed in

displayLanguage

LANG

Additional Content

Ticket encoder

Defines how the information is encoded. This could be plaintext, signed, encrypted, etc.

During integration, it is useful to configure a plain ticket encoder so that the tickets can be checked manually (e.g. looking at the transferred data).

For production use, we strongly recommend to use a ticket encoder that cryptographically protects the cookie:

  • Digital signature: make sure that only Airlock IAM can issue tickets (e.g. "JWT Ticket Encoder/Decoder")
  • Encryption: makes sure nobody can read the transmitted data (e.g. "JWT Ticket Encoder/Decoder")

Depending on the system setup, unsigned and/or unencrypted tickets may result in severe security vulnerability:

  • Anyone with the possibility to directly connect to the target application can impersonate any user.
    To mitigate this risk, use a signing or encrypting ticket encoder (e.g. JWT with adequate signature).
  • Anyone with the possibility to see the data being transferred to the target application can see what user is logged in.
    To mitigate this risk, use an encrypting ticket encoder (e.g. JWT with adequate encryption).