failing to download credentials file after 5/12 update about samltoawsstskeys HOT 28 CLOSED

Release 2.3 has just been published in the Chrome Web Store. Usually its available within 1 hour. If your browser does not automatically pulls in the update you can manually get it by restarting your browser.

Release 2.3 introduces the ability to enable/disable the SessionDuration. If you don't use it it is all left to the sdk and api to use the defaults (as it was in release 2.1 and downwards).

from samltoawsstskeys.

Since its actually the maximum session duration for your role which is causing the issue you might want to change this:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html#id_roles_use_view-role-max-session

As an alternative you might be able to change the requested session duration on Okta side.

from samltoawsstskeys.

Work around for those in need

Open up Chrome Extensions (go to this url chrome://extensions/)
Toggle Developer mode (top right corner)
Click on Details of the SAML to AWS STS Keys Conversion
Click on Inspect Views background/background.html (this will open the dev tools console)
Open the script.js file in the dev tools console
Go to line 144 and put a break point there
Navigate to awsconsole/
After you log in AND select an environment you breakpoint should be hit
Change the params.DurationSeconds to be 3599 (max allowable value for now)
Hit F8 and let the app continue.

You should now have a credentials file.

from samltoawsstskeys.

@prolane 2.3 works for me when i turn off SessionDuration. Thanks for working to get this resolved.

from samltoawsstskeys.

@derikwhittaker Thanks for the feedback. This can then be the workaround for everyone who is not able to either change its SAML provider settings or the IAM Role settings. I'm closing this issue.

from samltoawsstskeys.

Same issue here... :(

from samltoawsstskeys.

https://github.com/oktadeveloper/okta-aws-cli-assume-role

from samltoawsstskeys.

Same, but via Google

from samltoawsstskeys.

@rayhbo @AbbTek @estahn
Could any of you share the console output?

Most likely visible when you go to Extensions, turn on 'Developer Mode', and then click 'Inspect views background/background.html' for this particular extension. This will give you a new window with the console open. Try to use the extension and please share whatever output is generated.

from samltoawsstskeys.

Hi Guys I have the same problem.
The error message I see in the console is that exceeeds the maximum duration.

The maximum duration in aws is set to
Maximum CLI/API session duration 1 hour

But when I see in the post form data is requesting which indeed exceeds the 1h.

Action: AssumeRoleWithSAML
DurationSeconds: 14400 (4h)

Error: The requested DurationSeconds exceeds the MaxSessionDuration set for this role.
at constructor.s (aws-sdk-2.7.5.min.js:35)
at constructor.callListeners (aws-sdk-2.7.5.min.js:36)
at constructor.emit (aws-sdk-2.7.5.min.js:36)
at constructor.emitEvent (aws-sdk-2.7.5.min.js:35)
at constructor.e (aws-sdk-2.7.5.min.js:35)
at a.runTo (aws-sdk-2.7.5.min.js:37)
at aws-sdk-2.7.5.min.js:37
at constructor. (aws-sdk-2.7.5.min.js:35)
at constructor. (aws-sdk-2.7.5.min.js:35)
at constructor.callListeners (aws-sdk-2.7.5.min.js:36) "ValidationError: The requested DurationSeconds exceeds the MaxSessionDuration set for this role.

from samltoawsstskeys.

Is there are a way maybe to expose an option to specify the default value in the UI? And also to opt out from the automatic detection? I can confirm debugged via chrome the
var roleDomNodes = domDoc.querySelectorAll('[Name="https://aws.amazon.com/SAML/Attributes/Role"]')[0].childNodes
returned 14400 seconds. But for my role the default is set to 1h in IAM.

from samltoawsstskeys.

Do we have a work around for this? We have a large team which has come to depend on this tool for their daily AWS workflow.

from samltoawsstskeys.

@ggili Great, thanks! To be honest, this seems to be an issue from Okta side then. Because apparently Okta is requesting a too high SessionDuration.

I do like the suggestion to configure the default value.

from samltoawsstskeys.

I was able to get the credentials file to download by manually changing the SessionDuration value in the script.js file (used 900) for testing. Found that 3599 was the max value I could use.

This is line 136 in the script.js file.

from samltoawsstskeys.

@derikwhittaker Are you saying having the DurationSeconds set to 3600 does not work for you?
This is the default for when you don't supply the session duration.
https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html

Also, 3600 works for me for roles which are set to a 1 hour maximum session duration.

Update:
Just tested like you suggested above. When I set params.DurationSeconds to 3601 is when it breaks. 3600 works fine as may be expected.

I think the main issue still is the session duration requested by the IDP is higher than the max allowed session duration configured for your role. This needs to be fixed either at IDP side or at IAM role side.

How is this for you @derikwhittaker? Does your IDP request a certain session duration? And to what max session duration is your role set?

from samltoawsstskeys.

We're also hitting this. Using AzureAD for SAML federation; the SessionDuration in SAML is 7200 seconds but in IAM our roles are configured for CLI/API access max 1 hour duration.

We can work round by updating the roles but this would be quite a large job. It would be great if the extension were fall back to the previous behaviour in the event that it failed to assume a role with an explicit duration.

from samltoawsstskeys.

@derikwhittaker You can increase the timeout on the IAM role to the same number as the xaml has that would work fine then.

I cannot do that so I put a breakpoint to the scripts.js and change it manually in the debuger :)

from samltoawsstskeys.

We had the same issue and solved it by aligning SessionDuration in the SAML and max_session_duration for the AWS IAM role.

from samltoawsstskeys.

Thats right @gbvanrenswoude, this is what should be done for those who experience this issue. I guess you could say this new feature in the chrome extension just revealed that some companies have a mismatch between what they configured at their IDP side and what they configured at AWS IAM side.

from samltoawsstskeys.

@prolane yes, when I did 3600 i got an error, 3599 did not.

@ggili i am unable to change my IAM role as we are using SSO for AWS (enterprise accounts) and making this change would involve an act of god. Ok not really, but not able to get anything changed at this point so changing to 3599 works for now.

from samltoawsstskeys.

I need to add a proper case for the 400 Bad request it returns from AWS and then just AssumeRole with the default value (unless someone beats me to it).

Sorry about that noise, thought I had it correctly in that regard that it would silently fail and use the max on the AWS side. :(

from samltoawsstskeys.

I can confirm that I was not able to set the role STS expiration to 3599 seconds, the AWS UI would not accept that value, however, selecting 12h made it work.

from samltoawsstskeys.

Latest update broke the extensions for me. Console shows this error:

saml:1 Error in event handler for (unknown): TypeError: e.replace is not a function at containsSubString (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:91:30968) at textFieldScore (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:91:31072) at chk_form_has_totp (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:91:22580) at checkForTotpForm (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:91:21970) at setupIcons (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:79:23534) at chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:69:18481 at a (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:59:5243) at Object.apply (chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:39:40) at chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/onloadwff.js:69:1557

from samltoawsstskeys.

@prolane Given the amount of people using this, maybe it's best to back out my change to ease the disruption while I resolve some of these issues? Would hate to impose on you for a new release though.

from samltoawsstskeys.

@okachobi hdokiejnpimakedhajhdlcegeplioahd seems to be LastPass, not this extension.

from samltoawsstskeys.

@ashemedai I'm thinking to make a release tonight which enables you to opt out for using the session duration request from the IDP. That should solve the issue.

from samltoawsstskeys.

@prolane Sounds good. I want to make sure I got these 400 and possible 403 (when you lack
sts:AssumeRole permissions) responses tackled.

I find the 3599 case utterly weird though. Almost like an off-by-one, but it makes no sense in all these contexts. Especially given it would previously default to 3600 with AssumeRole() without the DurationSeconds parameter.

from samltoawsstskeys.

@ashemedai Yeah, the 3599 is really weird. I tested myself and for me it only breaks with 3601 for a role limited to 1h, so thats totally as expected. What I'll try to do is if you opt out, then just use the default again like before (i.e. not specifying the DurationSeconds).

The error handling you're talking about sounds good 👍

from samltoawsstskeys.