How to specify an event using SAML RelayState

Overview

This article describes how to create a RelayState value for Brazen (either IdP initiated SSO or SP initiated SSO) to redirect a user to a specific event after SSO is successful. A full description of RelayState can be found in Section 3.5 "HTTP POST Binding" of the SAML 2.0 Binding Specification: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.

Brazen will only support the HTTP POST binding for IdP initiated SSO. This is because the AuthnResponse message typically will exceed the URL length limits for user agents. Source: Section 4.1.3.5 of the SAML 2.0 Profiles Spec (http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf#page=17)

What is RelayState?

According to Section 3.1.1 of the SAML 2.0 Bindings specification: RelayState is a "mechanism for preserving and conveying state information". The specification doesn't say what this state information, it only defines the maximum size of the state to be 80 characters.

How does Brazen use RelayState?

Brazen uses the RelayState to indicate to where a user is to be redirected after the user is successfully logged into Brazen.

The Brazen RelayState is a URL that specifies one of these protocols:

Protocol	Usage	Example
https://	indicates the user is to be redirected from the Brazen app to another location.	https://app.domain.com/confirmation
brazen://	indicates the user is to be redirected to a location within the Brazen app. Use a URL that follows this pattern to send a user directly to an event after SSO: brazen://event/{event_code}	brazen://event/aAe2d/

Why doesn't Brazen require a checksum or hash of the RelayState to prevent tampering?

The SAML specification acknowledges that "signing is not realistic given the space limitation" of 80 characters (Section 3.5.3). However, it suggests that since "the value is exposed to third-party tampering, the entity SHOULD ensure that the value has not been tampered with by using a checksum, a pseudo-random value, or similar means." (Section 3.5.3). However using a checksum or hash function to ensure the RelayState hasn't been altered in transit is not feasible with a limitation of 80 characters. First, unkeyed cryptographic hash functions that are available in most languages and that produce short hashes (<= 32 characters in length using hexadecimal encoding) such as MD5 are weak and can be easily attacked using a average laptop. Second, secure unkeyed cryptographic hash functions produce hashes (e.g. SHA-256, SHA-512) take up more than half of the 80 characters allowed. Finally, implementations of non-cryptographic hash functions that produce small hashes like CityHash, MurmurHash and SpookyHash while available in open source, aren't part of many standard languages, adding extra work to address a small risk from tampering.