cratis-arc-authentication-authorization-and-identity

Authentication, authorization and identity in Arc

Arc separates three things that are easy to conflate: authentication decides who the caller is, authorization decides whether that caller may run this command or query, and the identity provider decides what the frontend is told about them. Each has its own extension point.

Verified product sources

Read references/product-sources.md when you need the owning package for an identity type.

Authorization capabilities arrived over time: named policies, schemes, fallback baselines, guest policies and Microsoft-attribute enforcement all need a recent Arc. authorization lists the requirements; check them if you run an older version.

Read this first: what is and is not trusted

Arc's shipped authentication reads a forwarded principal from HTTP headers. x-ms-client-principal is base64, not a signature, and Arc does not check who sent it. Any caller that can reach the application can author the entire serialized principal.

That is not a defect — it is the EasyAuth/reverse-proxy model, where the ingress is the trust boundary. But it means:

• the application must be unreachable except through the ingress that sets those headers, and that ingress must authenticate callers, strip any caller-supplied identity headers, write its own trusted replacements, and block direct access to the backend;
• nothing Arc gives you makes the forwarded values authentic;
• Arc ships no OpenID Connect and no JWT bearer integration. If you need the application itself to validate a token, that is ordinary ASP.NET Core authentication you configure yourself.

Requires Arc 22.43.0 for secure forwarded-header handling. On an older Arc the unsigned identity headers are trusted from any caller who can reach the host; upgrade, or make the ingress the only path to the backend.

Forwarded identity headers are ignored unless the host opts in with Cratis:Arc:TrustForwardedIdentityHeaders=true or builder.AddCratis(options => options.TrustForwardedIdentityHeaders = true). Header-only requests otherwise remain anonymous. AddCratis() still registers the header scheme; it does not make the headers trusted. Opt in only behind the ingress above, otherwise configure a credential-validating scheme. The old Introspection:TrustForwardedIdentityHeaders setting is obsolete and enables the same host-wide flag. See authentication. Source: secure defaults.