Anyone using everbridge.net with SAML and running into 414 status?

[Mike Osterman]

We have a SAML SP service that has been working just fine for years, but they are now updating SSO certificates, and I'm running into an issue where the Duo flow is breaking because of the length of the URI in the initial SAML request. Specifically, I can get past the password prompt, but once the flow redirects to Duo, Duo's API rejects the response with "414 Request-URI Too Large"

I'm going to contact the vendor support as well, and I suspect that's likely where the issue is coming from, which Duo support suspects as well:

  The HAR shows the request and the 414 error returned. I was able to review the SAML request, but only after URL decoding the request twice before I could Base64 decode and Inflate the request.

    Seeing that the SAML request is URL encoded multiple times before being sent to Duo, I suggest reviewing the SP settings to determine why it is encoding the request multiple times, adding to the length and causing the failure.

 The request URL is 10550 chars long when it returns the 414.

That said, I'm wondering if others have run into this behavior and already know what the resolution is.

Thanks!

Mike

[Mike Osterman]

A quick update to close the loop: 

While the root behavior of the super long Request URI is still not solved, we did find that the vendor SP was behaving in an unexpected way: The vendor UI for configuring how the SP should initiate the SAML flow had form fields for the request binding type and location to use, but no matter what we selected, the SP was reading the IdP metadata and choosing the first binding, which happened to be HTTP-Post rather than HTTP-Redirect. The latter was selected on the configuration form, but was getting ignored/overwritten. Since the SP only accepts metadata as a file, I was able to to reorder our bindings to put HTTP-Redirect first, and now we're back in business.

-Mike