Release v22.31.0

Added

• A named Arc authorization policy can opt in to being evaluated for unauthenticated callers: AddArcAuthorizationPolicy<TPolicy>(name, evaluatesAnonymous: true). The policy then receives an empty, unauthenticated principal and decides whether to allow the guest. This works the same with Arc's [Authorize] and ASP.NET Core's [Authorize(Policy = ...)], for commands, queries and observable queries. (#2761)
• AddArcAnonymousAspNetAuthorizationPolicy(name) gives the same opt-in to a policy registered through ASP.NET Core. It is checked at startup: the name must resolve to exactly one ASP.NET Core policy that doesn't require an authenticated user. Otherwise startup fails with InvalidAuthorizationConfiguration. (#2761)

Changed

• Policies without the opt-in behave as before and still require an authenticated caller. Role requirements and authentication-scheme requirements always require an authenticated caller, even when combined with an opted-in policy. If several policies apply, a guest is only evaluated when every one of them opted in. (#2761)
• Arc's method-level authorization replaces the type-level declaration. A method with an opted-in policy is therefore reachable by guests even when its type requires a role. The authorization docs now call this out. (#2761)

Security

• For commands and queries protected by a policy or authentication scheme, Arc checks the caller and the authorization requirements again immediately before the handler, query method or controller action runs, and denies the request if either changed after the policy verdict. (#2761)
• Missing or conflicting authorization configuration now denies the request with Unauthorized (403 at the HTTP endpoints) instead of running it or returning a server error, including when a custom command or query pipeline is registered. (#2761)

Decision 0006 records this and amends decision 0004.