[Authorize] attribute denies anonymous users, but setting any properties (like roles) does not

[abebehailu]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hi,

I have noticed a behavior that feels unexpected when setting the Authorize attribute on an endpoint. The reason seems to be the way the AuthorizationPolicy.cs is written.

Setting [Authorize] attribute leads to DenyAnonymousAuthorizationRequirement being applied (based on default policy) which denies anonymous users. While setting [Authorize(Roles = "a-role")] only authorizes the role and does not apply the requirement. Which is not obvious.

To test this behavior I have setup an authentication handler that succeeds by setting a user with the specific role in the http context but without an authentication type i.e. unauthenticated. I would expect the user to be denied in both the cases [Authorize] and [Authorize(Roles = "a-role")]. However, setting the attribute [Authorize] rejects the request with 403 while the other one passes through.

From the looks of it, in the AuthorizationPolicy.cs, if no properties are set on the authorize attribute it falls back to the default policy which applies the requirement.

Would it not make sense to combine the roles requirement with the default policy when using [Authorize(Roles = "a-role")] attribute, or maybe have a property to enable it? E.g. when creating policies you have the opportunity to call the RequireAuthenticatedUser to apply the deny anonymous user requirement, but the feature does not seem to exist on the attribute level. To achieve this you have to either add a policy and set it on the attribute explicitly, or call .RequireAuthroization on the AuthorizationEndpointConventionBuilderExtensions that basically adds the [Authorize] attribute.

Expected Behavior

Combine the roles requirement with the default policy when using [Authorize(Roles = "a-role")] attribute or add a attribute level property to enable it when setting the attribute on an endpoint e.g. [Authorize(RequireAuthentication=true, Roles="a-role")].

Steps To Reproduce

• Add an authentication handler that sets a user without an authentication type and with role claim "a-role" and make it always succeed.
• Add the [Authorize] attribute on an endpoint and make a request. You will get 403.
• Add the attribute [Authorize(Roles = "a-role")] on an endpoint and make a request. You will pass through.

Exceptions (if any)

No response

.NET Version

9.0.101

Anything else?

No response

[MackinnonBuck]

Thanks for reaching out.

Unauthenticated users with roles is not a common scenario. How do you know the roles of an unauthenticated user?

[abebehailu]

Hi,

I agree that the role case is not typical and you have a valid question. I am more concerned of the implicit trust in that any property set on the attribute implicitly assumes that a user is authenticated. Instead of assuming, is it not better that the deny anounymous user requirement is applied to guarentee it? Just like when the [Authorize] attribute is set.

If you think the implicit assumption is enough to minimize risk for potential misconfiguration issues, then I guess this i a non issue from that point of view. Either way, I think it would be more clean and future safe to apply the deny anonymous user requirement even in the other cases. :)