Not working with Federated SAML Auth about cloudfront-authorization-at-edge

[ottokruse]

Reproduced this issue and tracked it down to what I think is a bug in the Cognito hosted UI. The button to sign you in has a malformed link in it. Malformed because URL encoding has been undone:

onclick="window.location.href='/oauth2/authorize?identity_provider=azuread&redirect_uri=https://dtnlf3ngbtlae.cloudfront.net/parseauth&response_type=CODE&client_id=2knta0on4nrficrr56eomlnlat&state={\"nonce\":\"Tmaw0sx_MzhSLUrL\",\"requestedUri\":\"\/\"}&code_challenge=Dz9TSnEQ4qvZ

Now the "{" and "}" in the state parameter in there trigger the error. If you change them manually to %7B and %7D, their proper URL encoded values, then the URL does work and you sign in nicely.

The Lambda@Edge functions we use to redirect to Cognito, do use nicely encoded URL's, with %7B and %7D in there, but this is apparently decoded somewhere by Cognito when forming the link under the button.

We could probably work around this issue by not using an URL encoded JSON object, but then another scheme must be invented to encode the two state values (nonce and requested uri) in one string. I might get to that but meanwhile I will log this issue to the Cognito team also. I suggest you do the same, if this is important to you (raise a support ticket).

[ottokruse]

Hi. Thanks for reporting this. I haven’t spend any time at all at making this work with SAML federation. Would be great if it did. I’ll try, when I have bandwidth, to spin up a saml idp and test this. If you can help out with this, creating a testing setup, that would help speed things up.

[rikkuness]

I've had this example working with SAML but providing it was the only enabled provider on the user pool client, I was assuming the bug I saw was more to do with having multiple IDPs

[ottokruse]

Which bug did you see @rikkuness ?

[rikkuness]

I was getting an empty 400 response from Cognito itself, it only actually manifests when I enable more than on IDP on the Cognito client. From inspecting the requests the only difference I could see was an additional field on the querystring for identity_provider but I didn't delve too much deeper.

[ottokruse]

So you did get it working with one SAML IDP @rikkuness . It would be great if you provide some pointers on your setup for @philross88 because he had issues setting it up. Or is the pointer to use only 1 federated IDP (SAML)?

[rikkuness]

Yeah I don't think I did anything funky to get it working with SAML, as long as it's the only IDP on the client it seems to just default to that one and work okay!

[ottokruse]

@philross88 can you give that a shot? Only allow the SAML IDP in your app client federation, not Cognito User Pool?

Then we need to figure out why this would not work for multiple IDP's. I still need to reproduce that though

[ButkiewiczP]

Just want to confirm that I'm seeing the same issue here, and that enabling only the SAML provider works.

I'm using a SAML provider, and a Cognito User Pool.

When trying to login with both providers enabled, only the Cognito user pool works. When attempting to sign in using SAML (clicking the button on the cognito page), I'm redirected to this URL: https://auth-xxxxxxx.auth.us-east-1.amazoncognito.com/oauth2/authorize?identity_provider=MySAMLProvider&(...rest of query strings here).

The only difference between this and the URL when using a single provider, is the addition of the identity_provider parameter in the query string (as noted by @rikkuness above). The rest of the parameters (state, requestUri, etc) all exist as normal. The identity_provider parameter doesn't appear when enabling only one provider.

Additionally, If I launch the Cognito Hosted UI from the console, with both providers enabled, then I am able to login with SAML provider, but the parseauth function fails on the callback, because a state variable isn't passed back in the query string, only a code parameter.

[philross88]

Sorry for late reply. I did the exact same thing (removed these) as a workaround and it's working fine now.

…

On Thu, Feb 20, 2020 at 7:39 AM Otto Kruse ***@***.***> wrote: Reproduced this issue and tracked it down to what I think is a bug in the Cognito hosted UI. The button to sign you in has a malformed link in it. Malformed because URL encoding has been undone: onclick="window.location.href='/oauth2/authorize?identity_provider=azuread&redirect_uri=https://dtnlf3ngbtlae.cloudfront.net/parseauth&response_type=CODE&client_id=2knta0on4nrficrr56eomlnlat&state={\&quot;nonce\&quot;:\&quot;Tmaw0sx_MzhSLUrL\&quot;,\&quot;requestedUri\&quot;:\&quot;\/\&quot;}&code_challenge=Dz9TSnEQ4qvZ Now the "{" and "}" in the state parameter in there trigger the error. If you change them manually to %7B and %7D, their proper URL encoded values, then the URL does work and you sign in nicely. The ***@***.*** functions we use to redirect to Cognito, do use nicely encoded URL's, with %7B and %7D in there, but this is apparently decoded somewhere by Cognito when forming the link under the button. We could probably work around this issue by not using an URL encoded JSON object, but then another scheme must be invented to encode the two state values (nonce and redirect url) in one string. I might get to that but meanwhile I will log this issue to the Cognito team also. I suggest you do the same, if this is important to you (raise a support ticket). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=ACTRALV7CDM6RD7CGPD3ISTRDZ2X7A5CNFSM4J7CIJ42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMNXC6A#issuecomment-589001080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTRALS4ORIWW3H6ODBJUZ3RDZ2X7ANCNFSM4J7CIJ4Q> .

[ButkiewiczP]

I've opened PR #32 with a pretty primitive change that will enable you to use this with multiple identity providers. There might be a cleaner way, but this is currently working for our application.

[ottokruse]

Work around implemented in #32 by @ButkiewiczP

I have filed the original issue to the Cognito team. Closing this issue here now.