17.2.6.6. SAML single logout (SLO) with temporary Gateway Role

If one or more SPs are protected by the same Airlock Gateway (WAF) as the IDP, a special setup may be required for single logout (SLO) to work properly.

Affected scenarios and problem description

  • The following configuration hints apply to scenarios with all the following properties:
  • The IDP and an SP are accessed via the same gateway instance.
  • The IDP and the SP use the same session domain (from the web browser's point of view, they share the gateway session).
  • The SP is protected by a gateway role.
  • SLO (single-logout) is used.

In such scenarios, the SLO will not work because - for the sake of security - the IDP terminates the gateway session on logout. This prevents subsequent SLO requests from reaching the SP because the role protecting the SP is no longer in the gateway session. Thus, the SLO flow cannot be completed successfully.

Solution and configuration

Airlock IAM allows you to configure an additional temporary gateway role that is used only during the single logout. Together with the corresponding Access Rule configuration in the Airlock Gateway (WAF) mapping, the SP protection can be optimized:

  • The SP and the corresponding target application remain protected by an application-specific gateway role.
  • Only the SP is accessible during the SLO phase for only a short time (role timeout).

To implement the solution, configure Airlock IAM as follows:

  • 1.
    Go to:
    Loginapp >> SAML Settings >> SAML IdP Settings (Flow Auth)
  • 2.
    In the property Temporary Single Logout Gateway Credential , add a new Static Gateway (WAF) Role plugin and configure it as follows.
  • 3.
    Choose a role name like samlslo.
  • 4.
    Choose a sensible Idle Timeout and Lifetime (in seconds). For the sake of security, it should be as low as possible but guarantee that the SLO flow terminates even with slow connections (e.g. mobile connections). A value of 60 is recommended for both properties.
  • 5.
    Activate the configuration.

To make use of the temporary role in Airlock Gateway (WAF), adapt the gateway mapping covering the SAML SP as follows:

  • 1.
    Go to:
    Application Firewall >> Reverse Proxy
  • 2.
    Choose the mapping used for the SAML SP and switch to the Access tab.
  • 3.
    According to the description of the affected scenarios (see above), the mapping should already restrict access to all or some paths to a role (the role sp1 in the example below).
  • 4.
    Add new Access Restriction covering all SAML SLO endpoints of the SP and protect it with role samlslo.
    Example:
    • Method: ^GET$|^POST$
    • Path: ^%ENTRYDIR%/sp1/SPSloResponder.*$
    • Invert button: OFF
    • Restricted to Roles: samlslo
  • 5.
    To make sure that other SP endpoints (everything without the SLO part) is only accessible with the original SP role (sp1 in our example) but not the temporary SAML SLO role (samlslo), the existing Access Restriction must exclude the SAML SLO endpoints.
    Example: if the original path was empty or something like ^%ENTRYDIR%/sp1/.*$ then it would have to be changed to:
     
    • Method: empty
    • Path: ^%ENTRYDIR%/sp1/SPSloResponder.*$
    • Invert button: ON
    • Restricted to Roles: sp1
  • 6.
    Activate the changes on Airlock Gateway (WAF).

Not using the temporary SLO role (samlslo) in the gateway configuration will result in unexpected behavior. The Airlock Gateway (WAF) only stores roles in the session that exist in the mapping configuration.

Alternative solutions (not recommended)

The alternative solutions are not recommended because they offer poorer security compared to the solution described above.

  • Remove the gateway role on the SP. This makes the whole SP (depending on the setup also the thereby authenticated target application) accessible to the public.
  • Create a separate gateway mapping for just the SLO part of the SP and do not restrict access to the mapping. This results in a more complex setup (requires regular expression on the entry path to select the mapping) and is less secure because the SLO endpoint of the SP is accessible at all times.