Session Duration about holochrome HOT 6 CLOSED

Awesome! I'll get to this ASAP.

from holochrome.

So, I thought this would be easy... but it's not. There are definitely intricacies to the SessionDuration parameter. When I add it to my HTTP request I get:

400: Invalid Credentials Parameter. The request sent by the client was syntactically incorrect.

My guess is that I cannot ask for a longer session duration from a "child" set of credentials when my "parent" (from Hologram) is using the default. Unfortunately, I don't have high confidence in my theory due to the fact I was unable to ask for a session < 1 hr either. Plus, their documentation states:

Call the AWS federation endpoint and supply the temporary security credentials to request a sign-in token. If you used one of the AssumeRole* APIs to get the temporary security credentials, then this request to the AWS federation endpoint can include the HTTP parameter SessionDuration to specify how long the federated consoled session is valid, up to a maximum of 12 hours.

I've opened a support ticket to see what's going on. I'll keep this ticket updated with the results.

from holochrome.

In fact, the sample code provided by them does not work!

from holochrome.

Unfortunately, this will occasionally error out depending on how the environment is set up. Due to this inconsistency, I don't feel comfortable adding the parameter at the moment.

From Amazon:

So it appears the problem is when you have an IAM role assuming another IAM role to get the temporary credentials. I have talked to the service team and they confirmed you can't set SessionDuration when the temporary credentials are retrieved by an IAM role against another IAM role. The documentation will be updated to reflect this detail, as at the moment it is not very clear. So basically you need an IAM user with long term credentials to make the STS AssumeRole API call to get the temporary credentials from the IAM role, then use the returned temporary credentials to build the SignIn URL.

I suppose we could attempt to intelligently retry upon receiving a 400 for that particular call. Do you think that'd be worthwhile?

from holochrome.

it makes sense, otherwise you could just keep granting yourself credentials
indefinitely. i dont think we(adroll) would use long term keys just to get
around this, so id lean towards not doing it.

im not sure you could even make it work, because hologram returns role
credentials anyway

On Mon, Aug 1, 2016 at 8:34 PM, Ryan Sydnor [email protected]
wrote:

Unfortunately, this will occasionally error out depending on how the
environment is set up. Due to this inconsistency, I don't feel comfortable
adding the parameter at the moment.

From Amazon:

So it appears the problem is when you have an IAM role assuming another
IAM role to get the temporary credentials. I have talked to the service
team and they confirmed you can't set SessionDuration when the temporary
credentials are retrieved by an IAM role against another IAM role. The
documentation will be updated to reflect this detail, as at the moment it
is not very clear. So basically you need an IAM user with long term
credentials to make the STS AssumeRole API call to get the temporary
credentials from the IAM role, then use the returned temporary credentials
to build the SignIn URL.

I suppose we could attempt to intelligently retry upon receiving a 400 for
that particular call. Do you think that'd be worthwhile?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAev1RDs8CUGVNosP_EF3rWlZ0zZVQn9ks5qbrrEgaJpZM4JXyW2
.

from holochrome.

It makes a lot of sense why they'd do this.

We're not planning on doing anything with long-lived keys either.

Too bad, this was exciting :|

Closing.

from holochrome.