Add support for "derived" execution attributes. #4384

millems · 2023-08-31T23:59:45Z

These execution attributes do not get stored in the execution attribute map. Instead, they read from or write to OTHER execution attributes in the execution attribute map. This allows us to deprecate old execution attributes and keep them in sync with the execution attributes that have replaced them without needing to read or write to the old attributes.

Included in this PR is adding derived execution attributes for all AwsSignerExecutionAttributes, SdkTokenExecutionAttributes and S3SignerExecutionAttributes, as well as deprecation of those classes and their attributes.

Other notable changes:

When the SELECTED_AUTH_SCHEME is already set when we execute the auth scheme interceptor, carry forward any properties that were already set in the selected auth scheme. This allows setting those properties using the old execution attributes early in the request pipeline.
Add dependency on http-auth-aws and http-auth from auth. This allows the mapping from old attributes to new properties to be defined where the old attributes are created. This also sets us up for a potential future where our existing signers can return a new-style signer.
Simplify the decision of when to use the old signing path or the new signing path. For presigners, always use the old signers. For everything else, use the old signers when the customer has overridden the signer OR we're using an old client that doesn't define any auth schemes.
Disallow duplicate signer and identity property names. This prevents weird bugs where setting one property could set another property (e.g. signing name for v4a setting the signing name for v4). This global-uniqueness property already exists in execution attributes.

gosar · 2023-09-05T08:17:35Z

Disallow duplicate signer and identity property names. This prevents weird bugs where setting one property could set another property (e.g. signing name for v4a setting the signing name for v4).

I think the global-uniqueness may be a bad limitation to have. What if 2 services build their own runtime plugins where they use the same name that's intuitive to each, and now when a customer tries to use both plugins in same application, they get errors? Even if there was some central coordination for AWS services, this will happen more easily with generic SDKs, even without runtime plugins, just with their own signers/identity providers. Say a customer used both AWS and a generic SDK from company1, or multiple generic SDKs from different companies.

This global-uniqueness property already exists in execution attributes.

But identity/signer properties are used as a property bag per AuthSchemeOption, so at a high level, it seems fine if same name is used across signers / identity providers.

Is this a necessary constraint for this PR?

These execution attributes do not get stored in the execution attribute map. Instead, they read from or write to OTHER execution attributes in the execution attribute map. This allows us to deprecate old execution attributes and keep them in sync with the execution attributes that have replaced them without needing to read or write to the old attributes. Included in this PR is adding derived execution attributes for all AwsSignerExecutionAttributes, SdkTokenExecutionAttributes and S3SignerExecutionAttributes, as well as deprecation of those classes and their attributes. Other notable changes: 1. When the SELECTED_AUTH_SCHEME is already set when we execute the auth scheme interceptor, carry forward any properties that were already set in the selected auth scheme. This allows setting those properties using the old execution attributes early in the request pipeline. 2. Add dependency on http-auth-aws and http-auth from auth. This allows the mapping from old attributes to new properties to be defined where the old attributes are created. This also sets us up for a potential future where our existing signers can return a new-style signer. 3. Simplify the decision of when to use the old signing path or the new signing path. For presigners, always use the old signers. For everything else, use the old signers when the customer has overridden the signer OR we're using an old client that doesn't define any auth schemes. 4. Disallow duplicate signer and identity property names. This prevents weird bugs where setting one property could set another property (e.g. signing name for v4a setting the signing name for v4). This global-uniqueness property already exists in execution attributes.