Adding support of Token for Temporary Credentials

[DanOertelt]

This library works fine when using full AWS credentials however it does not work when using temporary credentials like when running on EC2 instance and using the 'embedded EC2' credentials that come from the IAM.
The temporary credentials require one to add a token header, otherwise the request is not validly signed. While this can be theoretically added outside of this library, I would consider it actual part of the signing.

[DanOertelt]

Any chance reviewing this pull request, please?

Thanks, Daniel

[tsibelman]

@DanOertelt I already did you can see my comment inline

[DanOertelt]

I've to admit I'm new to Github, but I can't just locate any inline comment. And I've tried to look pretty hard. It is still possible I'm missing it, but...

Thanks, Daniel

[tsibelman]

Thank you very much for your pull request, but I think this change can be a bit confusing for the users, as I see in the documentation

"... When you add the X-Amz-Security-Token parameter to the query string, some services require that you include this parameter in the canonical (signed) request. For other services, you add this parameter at the end, after you calculate the signature. "

So dependent on the service used it may act differently, right now the code is not handling this distinction and implements only the second strategy, for with you actually don't need to do anything special. As a user of a library if I encounter the option to pass x-amz-security-token, I would expect it to support the first scenario.

I personally used this library only for API Gateway communications but right now it not blocking other use cases.

Do you also use it for API Gateway?

[DanOertelt]

Thanks for the review, Yes, I use it for API Gateway too right now. It took me a bit to figure out why the code stopped working when deployed to EC2. In the end I realized that using the temporary credentials requires me to add the Token as well (locally, I used permanent credentials, hence it worked).

Yes, I get your point. The documentation indeed sounds as if there are two ways in which one should include the Token depending on the service. Handling it properly would require the library to know which service uses which approach and then implement both cases.

Implementing both cases does not seem to be a problem. But knowing which service uses which could be a problem. Or should the API of the library allow the user to actually specify which case they want to use? Thoughts?

[tsibelman]

Ideally one of the two scenarios could be detected based on the service name, but I don't know where the list of service behaviors can be found, so until such list exists it needs to be passed as some enum flag to a constructor.

But I don't sure if this makes anything that much simpler for the end user, is just as easy to add the header either before or after the signer is executed.

[DanOertelt]

Well, I honestly think detecting it on service name would be a nightmare as that would require constant maintenance and we know AWS is adding services in quite rapid pace.

I agree that the action of adding the header etc. is not that complex and hence you questioning if it makes sense to do it in the library is somewhat reasonable. However I would argue that just knowing how the header should be formed and what is its proper name as well as the mere presence of it in the method signature is of great value as it reminds the user of the library that there is something like a token that needs to be considered under certain circumstances.

I spent several hours wondering what is the culprit of my application using your library working locally and not working on EC2 instance could be before I ran into the token concept that I was not aware of.

[tsibelman]

I see that you saying if you could change your PR to address both scenarios I can merge it and publish a new nuget

[tsibelman]

@DanOertelt Sorry it looks like I commented but did not committed the review

[NeilBostrom]

@tsibelman @DanOertelt Shame this didn't go anywhere. I could really do with this feature.

[tsibelman]

@NeilBostrom it very easy to add this token in your own code, but problematic for a library to know when to add it

[joelbyren]

I was using this lib and got it working with user access key/secret, but I couldn't get it to work with temporary credentials (from assume role). Turned out I had not included X-Amz-Security-Token, and this reply helped me find it! Thank you!

[emonhaider]

I was using this lib and got it working with user access key/secret, but I couldn't get it to work with temporary credentials (from assume role). Turned out I had not included X-Amz-Security-Token, and this reply helped me find it! Thank you!

Can you please confirm if the header has to be added prior to signing the request?

[joelbyren]

I was using this lib and got it working with user access key/secret, but I couldn't get it to work with temporary credentials (from assume role). Turned out I had not included X-Amz-Security-Token, and this reply helped me find it! Thank you!

Can you please confirm if the header has to be added prior to signing the request?

X-Amz-Security-Token is added after signing. In the code I use, credentials does not always have a token (it depends on the credential used), so I use the UseToken property to know, and then the Token property as header value. This is with the C# version of AWS SDK.

[albertocorrales]

Could this PR be merged? I also needed to add the token header in my code after signing, so it would be awesome if this was added as part of the sign method, being token optional.

[ltoshev]

I don't think you need this PR, you just pass your token outside here is a sample:

var signer = new AWS4RequestSigner(parts[0], parts[1]);
var content = new StringContent(JsonConvert.SerializeObject(obj), Encoding.UTF8, "application/json");
var request = new HttpRequestMessage
{
Method = HttpMethod.Post,
RequestUri = new Uri(url),
Content = content
};
request.Headers.TryAddWithoutValidation("X-Amz-Security-Token", parts[2]);

        try
        {
            request = await signer.Sign(request, "execute-api", "eu-west-1");
            var client = new HttpClient();
            var response = await client.SendAsync(request);
            var responseStr = await response.Content.ReadAsStringAsync();
            var resp = JsonConvert.DeserializeObject<InvalidateCacheResponse>(responseStr);
            return resp.Success;
        }
        catch (Exception ex) 
        {
            ExceptionManager.Publish(ex);
        }