undefined | Better HN

0 pointsmooreds1y ago0 comments

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?

0 comments

ucarion1y ago

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.

j / k navigate · click thread line to collapse