Components auth: basic services and components

[SteveSandersonMS]

The first step in implementing the auth spec, https://gist.github.com/SteveSandersonMS/60ca3a5f70a7f42fba14981add7e7f79

This PR contains:

• The underlying DI service, IAuthenticationStateProvider, and its server-side implementation that simply passes through the state from HttpContext.User
• The AuthenticationStateProvider component that adapts IAuthenticationStateProvider into a cascading value, so components can easily observe changes to the authentication state and optionally use it in procedural logic
• (Partial) The AuthorizeView component that consumes the auth state cascading value and lets developers easily show different UI states depending on authorization conditions purely using declarative code.
  • This is a partial implementation, because it's waiting for Move AuthZ policy types back into Policy and rejigger AddAuthorization #10021 to be merged. Until then, the authorization rule is purely "you're authorized if authenticated", as it lacks parameters to control authorization conditions based on policies/roles.

More auth PRs will follow.

[SteveSandersonMS]

Review note: I'll be adding E2E tests later in process of doing the whole auth thing, once the feature set is more complete. So not in this PR.

[rynowak]

Looks good. Looks like what I expected to see 👍

[rynowak]

nit: fields -> constructors -> properties

[SteveSandersonMS]

OK. Rather than go through another multi-hour CI process to make this tweak, I'm going to include it in my next auth PR.

[rynowak]

technically not correct, it returns "a task that blah blah blah"

[SteveSandersonMS]

OK. Rather than go through another multi-hour CI process to make this tweak, I'm going to include it in my next auth PR.

[rynowak]

Is this actually needed now that NotifyAuthenticationStateChanged is there?

[SteveSandersonMS]

Well spotted. Rather than go through another multi-hour CI process to make this tweak, I'm going to include it in my next auth PR.

[rynowak]

Food for thought. It appears that we want to (and support) raising this event on any thread. Do we want to document that as supported? Or do we want to try and make it enforced that you raise this on the sync context.

[javiercn]

I don’t think we want that. The callback should be responsible for calling Invoke or InvokeAsync when handling the event.

I’m wondering how good our support story is when a component calls Invoke

[SteveSandersonMS]

It's an interesting question. We could make the AuthenticationStateProvider aware of the sync context (it's already a scoped service), and we could use an async-event pattern (Task-returning delegates) so that all the handlers would be async functions running on the sync context, whether or not they need to be.

However, the AuthenticationStateProvider is intended as a low-level service that developers will commonly only be the producer of (if implementing a custom authentication system), not the consumer. To consume the authentication state, developers will typically use either the cascaded value or the <AuthorizeView>, both of which already marshal the flow onto the sync context for you.

So, since in common usage patterns this won't be an issue anyway, I'd prefer to keep the AuthenticationStateProvider simple and independent of this, letting any developers who choose to use this low-level service deal with their own Invoke/InvokeAsync as Javier mentions, like they would when subscribing to any other service that's separate from the rendering system.

[rynowak]

@SteveSandersonMS - something else I thought of late (sorry).

These need to go into the manually maintained section of the ref assembly. The reason why is that ref assemblies don't preserve the setter if it's non-public. You can use cc1b294 as an example.

[SteveSandersonMS]

Great reminder - thanks. This should be covered in today's PR in this commit: ad9ac55