Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer #3552

Conversation

muhammad-othman
Copy link
Member

Description

  • Added AuthScheme.Signer() method to retrieve the signer associated with this authentication scheme.
  • Retrieved identity resolver and signer for the current scheme and attach them to request context in BaseAuthResolverHandler.
  • Updated BaseAuthResolverHandler to allow children to override the signer.
  • Added AuthSchemeHandler to the pipeline (limited to S3 and AutoScaling for now).

Motivation and Context

  • DOTNET-7802

Testing

  • Ran the unit tests and integration tests for S3 and AutoScaling services.

}
}

protected virtual AbstractAWSSigner GetSigner(IAuthScheme<BaseIdentity> scheme)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this return ISigner. AbstractAWSSigner seems tired to a SigV4(a) signer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the signers do implement AbstractAWSSigner, and this is the type of executionContext.RequestContext.Signer
so we will have to cast it again anyway.
image

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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they could provide an implementation for the token provider property.

Although I'm adding (in a separate PR) a default token identity resolver that should always be available. So my understanding is if an operation specifies both token and SigV4 as supported auth schemes we'll be able to resolve them automatically.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dscpinheiro I mean we should check if the user defined a token provider and use it before using the new default token identity resolver.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dscpinheiro I mean we should check if the user defined a token provider and use it before using the new default token identity resolver.

Sorry, the second sentence was replying to Norm's question (On that note, if a service does use both SigV4 and Token how do you configure the service client for both?)

if (Credentials != null && !(Credentials is AnonymousAWSCredentials))
var identity = executionContext.RequestContext.Identity as AWSCredentials;

if (identity != null && !(identity is AnonymousAWSCredentials))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we should update AnonymousAWSCredentials to return null for GetCredentialsAsync so we can avoid having these special cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
image

Base automatically changed from muhamoth/DOTNET-7538-remove-CreateSigner to sra-identity-auth November 19, 2024 15:07
// var identityResolver = scheme.IdentityResolver();
// var identity = identityResolver.GetIdentity();
// var signer = scheme.Signer();
executionContext.RequestContext.Identity = this.Identity;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they could provide an implementation for the token provider property.

Although I'm adding (in a separate PR) a default token identity resolver that should always be available. So my understanding is if an operation specifies both token and SigV4 as supported auth schemes we'll be able to resolve them automatically.

@muhammad-othman muhammad-othman force-pushed the muhamoth/DOTNET-7217-sra-update-signer-handler branch from 80f0ae4 to ff810d1 Compare November 19, 2024 18:23
@@ -36,7 +37,9 @@ public IIdentityResolver GetIdentityResolver(IIdentityResolverConfiguration conf
/// <inheritdoc/>
public ISigner Signer()
{
return new AWS4aSignerCRTWrapper();
if (_signer == null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why this one doesn't assign the value where the field is declared? Is it because it'll try to load the CRT dependency?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, which will cause an exception if the user doesn't have the CRT dependency even if this service doesn't need it.
So unless we call this signer we shouldn't create an instance of AWS4aSignerCRTWrapper.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, that makes me think we should update the BaseAuthResolverHandler to also check if the CRT is available when there are multiple auth schemes and one of them is SigV4A (in that case, we should skip SigV4A and try to use one of the other auth schemes).

This can be done in a separate PR; Here's what the endpoints resolver does:

case "sigv4a":
{
// If there are multiple authentication schemes but the CRT dependency is not available,
// we will proceed to check the next value in authSchemes.
if (hasMultipleSchemes)
{
if (!IsCrtDependencyAvailable())
{
continue;
}
}

Copy link
Member

@normj normj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small comment and then I'm good.

public ISigner Signer()
{
if (_signer == null)
_signer = new AWS4aSignerCRTWrapper();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid weird threading issues can we use the Interlock class for this lazy setting.

Interlocked.Exchange(ref _signer, new AWS4aSignerCRTWrapper());

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@muhammad-othman muhammad-othman merged commit 3da7704 into sra-identity-auth Nov 21, 2024
1 check passed
@muhammad-othman muhammad-othman deleted the muhamoth/DOTNET-7217-sra-update-signer-handler branch November 21, 2024 16:38
muhammad-othman added a commit that referenced this pull request Nov 25, 2024
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
muhammad-othman added a commit that referenced this pull request Dec 19, 2024
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
muhammad-othman added a commit that referenced this pull request Jan 3, 2025
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
dscpinheiro added a commit that referenced this pull request Jan 12, 2025
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
dscpinheiro added a commit that referenced this pull request Jan 29, 2025
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
dscpinheiro added a commit that referenced this pull request Feb 15, 2025
…identity and signer (#3552)

* Update request pipeline to use the AuthSchemeResolver to resolve the identity and signer

* apply code review comments

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* Update sdk/src/Services/S3/Custom/AmazonS3Client.Extensions.cs

Co-authored-by: Daniel Pinheiro <[email protected]>

* update SignerTests

* Add IdentityResolverConfiguration to ClientConfigTests.KNOWN_PROPERTIES

* Add AuthSchemeHandler to MockElasticTranscoderClient.CustomizeRuntimePipeline

* Use Interlocked when creating AwsV4aAuthScheme.Signer

---------

Co-authored-by: Daniel Pinheiro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants