Ensure schemes aren't used on components authorization. Fixes #10570 #12239
Conversation
| throw new NotSupportedException($"The authorization data specifies an authentication scheme with value '{entry.AuthenticationSchemes}'. Authentication schemes cannot be specified for components."); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
But you could have multiple schemes and have the scheme act as a filter (that's how I recall it works today). Don't we want to be consistent with the rest of the platform?
There was a problem hiding this comment.
The schemes are passed in to the authentication system when used with server-side auth: https://github.com/aspnet/AspNetCore/blob/master/src/Security/Authorization/Policy/src/PolicyEvaluator.cs#L35
Given that server-side auth with have already happened at this point, there isn't really anything we can do here that would be consistent.
yes, you could filter but that not going to work with a passive scheme like bearer.
Since we can't be consistent, and we don't have a clear use case, it seems better to just block it.
There was a problem hiding this comment.
It's not supported at the IAuthenticationStateProvider layer, as that only has an API to get the "current authentication state" which is a ClaimsPrincipal. It doesn't have a way to get different principals for different schemes.
In the future we could choose to make a more advanced version of IAuthenticationStateProvider (e.g., ISchemeAuthenticationStateProvider) that has APIs for getting different authentication states for different schemes. If we do that then we could relax this limitation. But since we're not planning that for 3.0, this "fail hard" rule is to help people not get confused about the feature set.
There was a problem hiding this comment.
I guess we can do this in the future without breaking changes.
SteveSandersonMS
force-pushed
the
stevesa/reject-scheme
branch
from
739c419 to
d3eece5
Compare
ghost
deleted the
No description provided.