Add NoAuthRuntimePluginV2 and deprecate NoAuthRuntimePlugin

[ysaito1001]

Motivation and Context

#4413

Description

NoAuthRuntimePlugin was broken after aligning the auth implementation with SRA.

After the SRA alignment, the code generator follows models more faithfully; it injects noAuth into the default auth scheme resolver when an operation is annotated with @optionalAuth or @auth([]). However, this broke NoAuthRuntimePlugin since it wasn't actually configuring the auth scheme option resolver.

While fixing noAuth issues in the originating Smithy model is ideal (by adding appropriate auth traits), that may not always be possible, e.g. when a Smithy-convertible model doesn't support it natively.

This PR deprecates the existing NoAuthRuntimePlugin and introduces NoAuthRuntimePluginV2 that configures the auth scheme option resolver for noAuth.

Note:
NoAuthRuntimePlugin is registered as a default client runtime plugin in FluentClientGenerator.kt. This was a hack from before the auth implementation was aligned with SRA. The plugin continues to be registered by default for backward compatibility, but it's broken due to the lack of an appropriate auth scheme option resolver. NoAuthRuntimePluginV2 is not added by default and should only be used as an escape hatch. The ideal fix is to annotate operations with
the appropriate auth trait in the Smithy model whenever possible.

While users could implement the functionality of NoAuthRuntimePluginV2 themselves, the multiple attempts have been seen in the wild (with the confusion), and some customers cannot update their models for various reasons. It's reasonable to provide this utility to avoid repeated issues.

Testing

Added integration test in AuthDecoratorTest.kt

Ignore Semver compliance check since NoAuthRuntimePlugin has been #[doc(hidden)], and the check couldn't get the information out of it.

Checklist

• For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "client," "server," or both in the applies_to key.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[aajtodd]

If NoAuthRuntimePlugin is already registered by default and makes noAuth an available/configured auth scheme, why not just make it easier to register a custom auth scheme (option) resolver? Is it because ResolveAuthScheme is specific to each generated crate?

I feel like the user experience ought to be either of the following depending on whether they want it for specific operations or all operations:

client.operation()
     .foo(...)
     .bar(...)
     .customize()
     .config_override(config_with_no_auth_override)
     .send()
     .await

or at the client level configuring auth_scheme_resolver to return the no auth option.

---

I see a few use cases:

1. Users want to disable auth completely for all users -> model it at the service level
2. Users want to disable auth for certain operations for all users -> model it at the operation level
3. User's want to offer optionalAuth operations/service
4. User's don't/can't model this for reasons and they want to dictate the behavior at runtime to disable auth

Ideally people are moving to (1) and (2) but for (3) and (4) I'd want it to be very explicit about what's going and (IMO) force them to setup the custom auth resolver/config and customize/override operations.

I can disagree and commit to this though if this is the desired solution for the identified use cases.

[ysaito1001]

Is it because ResolveAuthScheme is specific to each generated crate?

Yes, that's for one; While we can code generate a custom no-auth resolver for them, it can only wrap the default auth scheme resolver, not the one dynamically configured in runtime components. For two, we can narrow the usage of NoAuthRuntimePluginV2 only to generic clients since the .runtime_plugin method is only exposed to them but not to AWS SDK. A custom no auth scheme resolver would be available to both generic and AWS SDK clients.

[rcoh]

Really? I thought we enabled runtime plugins for the SDK...

[ysaito1001]

Really? I thought we enabled runtime plugins for the SDK...

case in point, though it's configurable at codegen time

[ysaito1001]

@rcoh, do you still feel strongly about original recommendations or do you consider us doc-hiding NoAuthRuntimePlugin and only exposing no auth scheme resolver, knowing the non-functional NoAuthRuntimePlugin still registers no auth scheme in the orchestrator?

FYI, we kind of have a NoAuthSchemeResolver, but its usage is restricted to protocol tests.

[rcoh]

I don't really care the exact mechanism. But:

1. Having a NoAuthRuntimePlugin that doesn't work on its own is very confusing.
2. The errors you get don't point you at all in the right direction:

called `Result::unwrap()` on an `Err` value: DispatchFailure(DispatchFailure { source: ConnectorError { kind: Other(None), source: NoMatchingAuthSchemeError(ExploredList { items: [ExploredAuthOption { scheme_id: AuthSchemeId { scheme_id: "sigv4" }, result: NoIdentityResolver }], truncated: false }), connection: Unknown } })

Having a well documented cookbook about "here's how you disable auth" would probably do the trick that is linked from that error message.

The NoAuthSchemeResolver doesn't do the right thing since it needs to compose with the existing resolver.

If we wanted to, you could consider adding a method to config like allow_no_auth to the config that automates this process.

[ysaito1001]

Sounds good. Taking both @aajtodd and @rcoh's input into account, I'll proceed with:

• Defining allow_no_auth on the client config builder — I prefer this over disable_auth since the latter implies the no-auth scheme takes highest priority, while allow_no_auth better conveys that it's appended to the end of the auth scheme resolver's list.
• Adding a discussion page that describes allow_no_auth and linking to it from the error message.
• Doc-hiding the existing NoAuthRuntimePlugin.

[rcoh]

Actually one more consideration—we need to make sure that a runtime plugin can enable this or there is another ay for a service to vend a "working" client to customers which often involves doing some amount of custom settings. That's one thing that's nice about the existing RuntimePlugin approach — its easy for someone to provide a wrapper around the generated client that adds the runtime plugin (because a runtime plugin is always addable).

[ysaito1001]

Actually one more consideration—we need to make sure that a runtime plugin can enable this or there is another ay for a service to vend a "working" client to customers which often involves doing some amount of custom settings. That's one thing that's nice about the existing RuntimePlugin approach — its easy for someone to provide a wrapper around the generated client that adds the runtime plugin (because a runtime plugin is always addable).

OK, I was thinking to remove NoAuthRuntimePluginV2 and instead code generate pub(crate) counterpart used privately by allow_no_auth but sounds like we still want to keep NoAuthRuntimePluginV2 as-is in the PR, exposed as pub from the aws-smithy-runtime crate.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.