Hacker News Reader

Comment by mooreds | Hacker News Reader

Also worth noting that per the spec, the RelayState can only be 80 bytes.

> As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes

From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings...

At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details.

SAML is full of these kinds of gotchas. We have an open source library which provides Java SAML bindings: https://github.com/FusionAuth/fusionauth-samlv2

View on HN

Yeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status.

FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.

We've found some usage of http-redirect and support it. But we've gotten requests for Artifact and other more esoteric features (encrypted assertions). It's definitely an example of the 80/20 rule.

> We just implement SAML RelayState / OAuth `state` via good old database persistence.

I'm not sure I understand how this helps. You still need to support the parameter so that folks can pass information through the login state (for deeplinking, among other use cases). Which means you still need to process it and therefore are committed to either being noncompliant with the spec or providing functionality that is limited to 2005 sensibilities.

What am I missing?

What I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState.

For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.

It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.

Reply on news.ycombinator.com