By using AWS re:Post, you agree to the Terms of Use

Internal Server Error - SAML Federation for User Pools

0

Hi!

Attempting to get SAML federation for User Pools working. Have followed instructions as outlined here:
https://aws.amazon.com/blogs/mobile/amazon-cognito-user-pools-supports-federation-with-saml/

To trigger sign-in, we're running a local version of this example app:
https://github.com/aws/amazon-cognito-auth-js/tree/master/sample
When selecting to sign in via our SAML IdP, we're being redirected to the IdP login and after authentication we're successfully receiving a POST back to our
https://myapp.auth.eu-west-1.amazoncognito.com/login/redirect with a successful SAML assertion. NameID is set in the saml:Subject, and we're using the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (as specified in the above instructions)

We're then supposed to be redirected to our redirect_url with an idp token, but instead we see a GET to https://myapp.auth.eu-west-1.amazoncognito.com/error?error=Error%20occured%20while%20reading%20the%20IdP%20token.%20Internal%20server%20error (in the Cognito provided web pages)

"Error occured while reading the IdP token. Internal server error."

As a side note: we have also tried establishing a user pool in another region, but with the same result...

How can we find out what is going wrong? Would apprectiate any help :)

Regards, Kenneth

asked 5 years ago25 views
5 Answers
0

Thanks for reporting this. We are in process of fixing couple of bugs identified in our implementation.

  • Name id longer than 128 char results in error.
  • SAML response containing invalid base64 chars (new line or whitespace) results in error.

We are in process of fixing these and will update here once it is done.
Meanwhile if above two cases are not applicable for your scenario, can you please PM me approximate timestamp and user pool id so that i can investigate further.

answered 5 years ago
0

Hi Vinay, thanks for the response!

The nameId is a lot shorter than 128 chars. And the encoded SAML response does not contain any newline or whitespace characters.

Have also tried both with users that don't already exist in the user pool AND users that are already established (with user self-signup) within the user pool. Same problem for both.

Will PM you with details so that you can investigate furter :-)

Thanks a lot, Kenneth

answered 5 years ago
0

A follow up for others that might experience the same problem...

It did not look like our SAML response contained invalid chars, but after inspecting AWS logs:

Vinay:
"I can confirm that the issue is related to the invalid base-64 chars (new line). You will see %0D%0A chars in the url encoded base-64 response, which typical SAML decoder ignore. This is why you don't see it in the base-64 response.
We have the fix rolled out in Frankfurt, Mumbai and London region already. So, you should be able to get it working in any of these regions. Meanwhile we are rolling out the fix in other regions."


I attempted to get it working with a user pool in Frankfurt, but experienced the same problem there. However, when I tried London, things started to work! :-D

Guess the fix will be rolled out in multiple regions soon...

answered 5 years ago
0

Can you confirm this has rolled out on all regions, including us-west-2? I'm receiving a similar error, even when the IdP is showing success.

answered 5 years ago
0

The fix has been deployed to handle the new line chars in the URL encoded SAML response.

answered 5 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions