authorize A B requires both policies, but renders as Roles(A, B) which admits either

[woksin]

Summary

A command declaring authorize A B requires both policies. Stage renders it as [Roles("A", "B")], which Arc evaluates as either. A rendered application therefore admits callers the document does not.

This is present today and does not depend on any unreleased change.

Evidence

Adjacency means AND. PolicyReferenceSyntax.IsAlternative documents itself as "Whether the reference was introduced with or, making it an alternative to the preceding policies" — so a reference written without or is an additional demand, not an alternative.

Stage unions every reference regardless — Source/Rendering.Cratis/Authorization/AuthorizationRenderer.cs:67-78:

var required = declared
    .SelectMany(authorize => authorize!.Policies)
    .Select(reference => RolesRequiredBy(reference, applicationSet, subject, diagnostics))
    .ToArray();
…
var union = required.SelectMany(roles => roles).Distinct(StringComparer.Ordinal).Select(CSharpCodeBuilder.StringLiteral);
return $"Roles({string.Join(", ", union)})";

IsAlternative is never read.

Arc evaluates [Roles] as a disjunction — Arc.Core/Authorization/AuthorizationEvaluator.cs:123-124:

var requiredRoles = roles.Split(',').Select(r => r.Trim());
var userHasRequiredRole = requiredRoles.Any(user.IsInRole);

So authorize Administrator Auditor — meaning both — renders as a rule admitting anyone holding either.

Why no spec caught it

Both authorize fixtures build the reference list the same way, and can only produce disjunctions — for_AuthorizationRenderer/given/an_application_with_policies.cs:51:

new PolicyReferenceSyntax(policy, index > 0, SourceLocation.Start)

Every policy after the first is hard-coded as an alternative, so the conjunction case is unreachable from the specs.

The fix is constrained by what Arc can express

A faithful conjunction cannot be rendered with Arc as it stands:

• [Roles] is strictly OR (above).
• AuthorizeAttribute.Policy is declared but read nowhere — both evaluators return only (true, authorizeAttribute.Roles). See [Authorize(Policy = "...")] is never evaluated, so a policy-protected command admits any authenticated user Arc#2464.
• Stacking attributes does not work: AuthorizationAttributeEvaluator takes .FirstOrDefault() and ignores the rest, and RolesAttribute is not AllowMultiple.

So the honest rendering for a conjunction is [Authorize] plus a diagnostic — weaker than declared, never anonymous — rather than a Roles union that is wrong in the permissive direction.

Suggested direction

Cratis/Screenplay#68 replaces the flat list with a requirement tree, so the grouping becomes expressible. When Stage absorbs that:

• PolicyReferenceSyntax → existing RolesRequiredBy
• LogicalPolicyRequirementSyntax { Operator: Or } → the existing union, which is correct for a disjunction
• LogicalPolicyRequirementSyntax { Operator: And } → report it and render Authorize

Use the tree rather than References() — the flattened view discards exactly the information this bug is about.

Worth fixing the fixtures in the same change, so the conjunction case is reachable from specs at all.

[einari]

@woksin
I think we might have a confusion in policies and roles here.
Its natural to think that Arc requires all policies given to it, while roles is a little bit different - since roles basically is saying which roles are allowed.

While rendering we would need to understand the difference, and Arc needs to support policies explicitly and not rely on roles for policies.

[woksin]

@einari You are right, and it makes the issue above partly wrong — worth correcting before anyone works from it.

I framed this as "a conjunction rendered as a disjunction". The truer statement is the one you make: a policy is being rendered as roles at all, and that is where the meaning is lost. RolesRequiredBy resolves each policy down to the roles it happens to require and puts them in one Roles(...) list, so two different things get collapsed into one:

• roles — which roles are allowed. A list is naturally an OR, and Arc's requiredRoles.Any(user.IsInRole) is correct for that.
• policies — each one a demand the caller has to satisfy. Several of them is naturally an AND.

Once a policy has been flattened into its roles, that distinction is gone and no amount of care in the renderer recovers it. My suggested fix — detect the and and fall back to [Authorize] — treats the symptom and would leave policies still rendering as roles.

So the ordering is:

1. Arc supports policies explicitly — [Authorize(Policy = "...")] is never evaluated, so a policy-protected command admits any authenticated user Arc#2464. AuthorizeAttribute.Policy is declared and read nowhere: grep -rn "\.Policy" Source/DotNET --include="*.cs" returns no runtime hit, and both evaluators return only (true, authorizeAttribute.Roles). Until that changes there is nothing for Stage to render a policy into.
2. Stage renders policies as policies, and roles as roles, keeping AND across policies and OR within a role list.

That makes this issue blocked on Cratis/Arc#2464 rather than actionable on its own, so I have added the dependency rather than leaving it looking ready to pick up.

One thing from the original report still stands regardless of the fix: the specs cannot currently express the failing case. Both authorize fixtures build references with IsAlternative: index > 0, so every fixture is a disjunction and the conjunction path is unreachable. Whatever shape the fix takes, that wants fixing in the same change.