Could not call AssumeRoleWithSAML: Error: HTTP error: 400 about samltoawsstskeys HOT 18 CLOSED

@SlavaSubotskiy and @DavidRHoffman , thanks for the insights. Due to Chrome extension manifest V3 I was not allowed to use the aws sdk for javascript v2 anymore. This sdk contains some legacy javascript methods which Google does not consider safe anymore.

As an alternative, I've refactored into using plain javascript fetch to call the aws sts api directly. This works well in most cases, but my guess is the sdk does some extra magic when the SAML Assertion is very large (due to many claimed roles). Since both of you confirmed my theory, I'm guessing I'm on the right track here.

I'll refactor this api call into using the sdk for javascript v3 and I'll release a new version of the extension.

from samltoawsstskeys.

I am able to get it to work after unsetting SessionDuration requested by SAML provider.

from samltoawsstskeys.

@DavidRHoffman This is a different issue than #58. #58 was caused by the the various ways IDP's format the SAML xml document. The xmlparser in the extension was not correctly configured for this, which caused an error in reading the xml data. This has been fixed in v3.1 and users have reported the extension is working for them now.

The error you are posting here is beyond that part of the code. The IAM Role ARN that you are trying to assume, and the SAML Provider ARN, have been detected by the extension. Next up is the actual AssumeRoleWithSAML API call.

The SAML data sent with this API call is actually just a 1 on 1 copy of the SAML data passed by your IDP.

The HTTP 400 response code from AWS indicates there is something fishy with your SAML data. See the official AWS docs:
https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html#API_AssumeRoleWithSAML_Errors

It could mean one of these things:

• ExpiredToken
• InvalidIdentityToken
• MalformedPolicyDocument
• PackedPolicyTooLarge

Since I assume you are actually able to login using to the AWS Web console using SAML SSO, my first guess is the error is 'PackedPolicyTooLarge'. Just to get some idea of what might be going on, are you eligible to assume many different IAM Roles within your organisation?

from samltoawsstskeys.

@DavidRHoffman You can get some more details on the error by manually loading the extension version from this branch: https://github.com/prolane/samltoawsstskeys/tree/asumerolewithsaml-http-400

• Clone this repo and switch to the mentioned branch
• Open the extensions page in Chrome
• Disable the SAML to AWS STS Keys Conversion extension
• In the top left corner, click Load unpacked
• Select the directory where you cloned the repo
• Test again. You should now see the response text from AWS in the logs.

from samltoawsstskeys.

Hi @prolane!
I've got the same E400 on v3.1. Here is the debug output on yourasumerolewithsaml-http-400 branch:

from samltoawsstskeys.

Here is the content of the responses:

from samltoawsstskeys.

Just to get some idea of what might be going on, are you eligible to assume many different IAM Roles within your organisation?

@prolane yes, in my case there are 22 accounts with 47 roles in total.

from samltoawsstskeys.

More metrics for the failed https://sts.amazonaws.com/?Version=2011-06-15&Action=AssumeRoleWithSAML... request:

• Request URL has 22050 symbols
• SAMLAssertion option value in Request URL has 21849 symbols

from samltoawsstskeys.

I could get it to work with aws cli with same SAMLAssertion.

from samltoawsstskeys.

Just to get some idea of what might be going on, are you eligible to assume many different IAM Roles within your organisation?

Yes, you are correct, on the page "https://signin.aws.amazon.com/saml" I am eligible to assume multiple different roles in multiple different accounts in my organization. This was working fine in Chrome before the 3.0 update, and fortunately I can still use 2.5 in Firefox for now.

from samltoawsstskeys.

I've just submitted v3.2. Google will first do a review, but usually the new version will be published within one day.

Please let me know if this fixed the issue.

from samltoawsstskeys.

@prolane - I have v3.2, but the error I am getting is related to the fix for #62. The value that was passed for SessionDuration is 43200 seconds. This is coming directly from the attribute value in the samlXmlDoc that is decoded from details.requestBody.formData.SAMLResponse[0] in the onBeforeRequestEvent.

ValidationError: The requested DurationSeconds exceeds the MaxSessionDuration set for this role.
at Te (aws-js-sdk-bundle.js:2:57065)
at aws-js-sdk-bundle.js:2:70787
at async aws-js-sdk-bundle.js:2:38494
at async On.retry (aws-js-sdk-bundle.js:2:89037)
at async aws-js-sdk-bundle.js:2:116397
at async assumeRoleWithSAML (script.js:278:22)
at async onBeforeRequestEvent (script.js:197:12)

The AWS documention on this does include an explanation of where 43200 seconds comes from:

"When you use the AssumeRole API operation to assume a role, you can specify the duration of your role session with the DurationSeconds parameter. You can specify a parameter value of up to 43200 seconds (12 hours), depending on the maximum session duration setting for your role. However, if you assume a role using role chaining and provide a DurationSeconds parameter value greater than one hour, the operation fails."

I don't believe that the role chaining condition comes into play because am able to access the account with the assumed role for 12 hours, but maybe it has something to do with the way the extension works.

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html

from samltoawsstskeys.

I'm seeing the same thing.

from samltoawsstskeys.

@DavidRHoffman @hrast01
Ok, thanks for the info. I will investigate and test at my end with an IDP requesting a SessionDuration of 12 hours.

However, could you please check the corresponding IAM Role in the web console and check what the configured Maximum session duration is?

from samltoawsstskeys.

@DavidRHoffman @hrast01
Like @sanjeevik89 suggested, you can continue with the default session duration, by using the options panel of the extension and choose not to apply the SessionDuration requested by your IDP.

from samltoawsstskeys.

Yep, I already made that change and it did download all the configured credentials correctly.

from samltoawsstskeys.

@DavidRHoffman @hrast01
I'm able to reproduce the issue, but I don't believe this is caused by the updated version. Let me explain.

• When my IDP sets the SessionDuration attribute to 43200 (12 hours) and the Maximum session duration on the Role to assume is set to 43200 as well, the extension will successfully call the AssumeRoleWithSAML api.
• When my IDP sets the SessionDuration attribute to 43200 (12 hours) and the Maximum session duration on the Role to assume is set to a lower value, for example 28800 (8 hours), the extension will fail call the AssumeRoleWithSAML api, returning the error mentioned: ValidationError: The requested DurationSeconds exceeds the MaxSessionDuration set for this role..

It is interesting to observe the AWS web console does allow you to continue assuming the role when the Maximum session duration on the IAM Role is set to a lower value than the IDP SessionDuration. Apparently AWS coded some additional logic in their backend when the SAML Assertion is posted to https://signin.aws.amazon.com/saml and they call the AssumeRoleWithSAML api.

Anyway, to validate if v3.2 of the extension somehow has different behaviour compared to v2.8 I did a checkout of commit eda22d7 and reloaded the extension. With the Maximum session duration on the IAM Role set to a lower value than the IDP SessionDuration is get the same error response from the AssumeRoleWithSAML api.

In short, I would say this is actually an error on the configuration side of the IDP. You should ask the administrator of your IDP to configure the SessionDuration to match the Maximum session duration of the IAM Role(s) you are allowed to assume.

On the bright side;
For now you can still continue using the extension by choosing not to use the IDP's SessionDuration attribute. This can be configured in the options of the extension, as mentioned by @sanjeevik89.
Also there is this PR: #55. I'm planning to review this one somewhere in the next 2-3 weeks. This will allow you to manually override the SessionDuration.

Hope all this gives you the right information to understand what's going on at your side. If I've missed something, or if you believe the configuration at your end is somewhat different and this needs more investigation, feel free to let me know and provide me with the additional details. For now, I'll consider this not as an issue but as a feature request.

from samltoawsstskeys.

PR #55 has been merged. Release 3.3 includes these updates.

from samltoawsstskeys.