Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer #3552
Conversation
…identity and signer
| } | ||
| } | ||
|
|
||
| protected virtual AbstractAWSSigner GetSigner(IAuthScheme<BaseIdentity> scheme) |
There was a problem hiding this comment.
Should this return ISigner. AbstractAWSSigner seems tired to a SigV4(a) signer.
There was a problem hiding this comment.
All the signers do implement AbstractAWSSigner, and this is the type of executionContext.RequestContext.Signer
so we will have to cast it again anyway.
Changing executionContext.RequestContext.Signer to ISigner wont be very simple since we do depend on signer referencing core internal types that need to be extracted / refactored (e.g. IRequest).
| /// <inheritdoc/> | ||
| public ISigner Signer() | ||
| { | ||
| return new NullSigner(); |
There was a problem hiding this comment.
For each of these schemes should the signer be a member variable so we can reuse the same instance instead of recreating the signer for every request?
There was a problem hiding this comment.
Will add a static readonly variable to cache the signer.
| // var identityResolver = scheme.IdentityResolver(); | ||
| // var identity = identityResolver.GetIdentity(); | ||
| // var signer = scheme.Signer(); | ||
| executionContext.RequestContext.Identity = this.Identity; |
There was a problem hiding this comment.
Doesn't this have the problem that if a service client has some operations that take AWS SigV4 credentials and others that take a token we will always use the identity passed into the constructor for the service client. Should we only use the identity passed into the constructor for the operations that support that type. Otherwise use the resolver.
On that note, if a service does use both SigV4 and Token how do you configure the service client for both?
There was a problem hiding this comment.
Yep I did miss that, will rename this.Identity to DefaultAWSCredentials and make sure that we use it for SigV4/SigV4a.
For the other note, we didn't allow the users to provide a Token when creating the client, however the could provide IAWSTokenProvider implementation, which should be respected when implementing SSO, right @dscpinheiro?
| if (executionContext.RequestContext.Identity == null) | ||
| { | ||
| var identityResolver = scheme.GetIdentityResolver(executionContext.RequestContext.ClientConfig.IdentityResolverConfiguration); | ||
| executionContext.RequestContext.Identity = identityResolver.ResolveIdentity(); |
There was a problem hiding this comment.
Confirming if we do go in here for every request and the identity is eventually resolved by hitting IMDS we wouldn't go to IMDS for every request correct?
There was a problem hiding this comment.
This shouldn't happen since we do cache the credentials in DefaultAWSCredentialsIdentityResolver.
| if (Credentials != null && !(Credentials is AnonymousAWSCredentials)) | ||
| var identity = executionContext.RequestContext.Identity as AWSCredentials; | ||
|
|
||
| if (identity != null && !(identity is AnonymousAWSCredentials)) |
There was a problem hiding this comment.
Wondering if we should update AnonymousAWSCredentials to return null for GetCredentialsAsync so we can avoid having these special cases.
There was a problem hiding this comment.
It should be even simpler than that, we can just return null for GetCredentials and GetCredentialsAsync has an implementation in the base class that just uses GetCredentials and we don't need to change that.
Now this made me think that we shouldn't need the BearerTokenSigner special case too that we have above, since the signer cannot be BearerTokenSigner when the Identity is AWSCredentials.
Description
AuthScheme.Signer()method to retrieve the signer associated with this authentication scheme.BaseAuthResolverHandler.BaseAuthResolverHandlerto allow children to override the signer.AuthSchemeHandlerto the pipeline (limited to S3 and AutoScaling for now).Motivation and Context
Testing
S3andAutoScalingservices.