Flow tags and red flags

Tags are properties acquired during a flow and they are stored in the flow session. Tags can be used to control the flow and act as guards ensuring particular steps have successfully completed.

  • The following attributes are stored in the flow session for each tag:
  • name
  • issue date
  • timeout (optional)
    • Currently, the following timeouts are supported:
    • Tag Lifetime – the tag expires after a configurable amount of time after it was issued.
    • Tag Idle Timeout – the tag expires after a configurable amount of time the HTTP session on the Airlock Gateway (WAF) was idle.

Typical examples of tag names are PASSWORD_VERIFIED or MTAN_VERIFIED.

Acquiring tags

Tags are issued by IAM upon successful completion of a step. The configuration property Tags On Success in the step configuration defines what tags are issued by the step.

Tag usage

  • Tags are for example used for the following (excerpt):
  • Preconditions on flow steps
  • Similar to assertions, tags can be defined as preconditions on steps. A step cannot be entered unless the required tags are available in the session.

    Security Hint

    We recommend using step preconditions to validate security properties on flows. For example, use tags to make explicit that a step can only be entered in case the condition PASSWORD_VERIFIED holds.

    These kinds of guarantees, a.k.a. guards, especially help to keep complex flows securely.

  • Skip conditions on flow steps
  • Tags are used in skip conditions in the step configuration. A step is skipped if the corresponding skip condition is fulfilled. To skip a step if one or more tags are present in the flow, use the Has Tag condition. This concept is for example used to implement step-up authentication.

  • Flow control with selection
  • Like with the skip conditions, the Has Tag condition can be used to control the flow in selections (see separate article).

  • Identity Propagation
  • Tags can be used to propagate roles and permissions in identity propagation.

Flow sessions and tag timeouts

When a flow is started, tags from the session are copied to the flow so the flow can use tags acquired in previous flows. This is, for example, essential when implementing step-up authentication.

Similarly, tags acquired during a flow are copied to the session after the flow has successfully completed.

Tag timeouts define how long a tag is valid.

  • Currently, the following timeout types are supported:
  • Tag Lifetime: the tag expires after a configurable amount of time after it was issued.
  • Tag Idle Timeout: the tag expires after a configurable amount of time the HTTP session on the Airlock Gateway (WAF) was idle.

Note that timeouts are evaluated only on the tags in the session and not on the tags issued during the flow. New tags are only evaluated with regard to timeouts once they have been copied to the session.

Red flags

Red flags have some similarities with tags in the sense that flow steps may raise and consume them.

  • There are however several aspects where red flags differ from tags:
  • Red flags only exist in the context of a flow. The red flag must be raised and consumed within the same flow.
  • Failure to consume a red flag before the end of a flow forces this flow to fail with a corresponding error.
  • Red flags have a clear semantic: Only specific steps may raise a particular red flag and only specific steps may consume this red flag.

Example:

A typical example of a red flag is the mandatory password change. Steps, e.g. the Username Password Authentication Step raises the red flag MANDATORY_PASSWORD_CHANGE to indicate that a subsequent step must execute a mandatory password change. This is normally handled by the Mandatory Password Change step. If no step consumes the flag, the flow fails.