Add AuthorizationPolicyBuilder.RequireClaim overload that take a Func<Claim, bool>

[joegoldman2]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Fixes #56331.

[joegoldman2]

PR created as draft, waiting for the API proposal review.

[halter73]

@joegoldman2 Did you see my last comment on the API proposal? I'm wondering what you think about leaving ClaimsAuthorizationRequirement unchanged and having RequireClaim(Func<Claim, bool> match) add an AssertionRequirement instead.

I'm hoping to go over this in API review tomorrow. I'm not saying we'd definitely approve the API with this modification, but it might make it more appealing since it'd reduce the size and impact of the change.

[halter73]

Thanks for your contribution. As you may have already seen, we decided to reject the API proposal (#56331). Ultimately, we did not find the example usage super compelling.

builder.Services.AddAuthorization(options =>
{
   // Checking if there is any claim that starts with a certain prefix
   options.AddPolicy("prefix", policy => policy.RequireClaim(claim => claim.Value.StartsWith("prefix-"));
});

Aside from yours, we haven't heard many requests to define a policy where a user must have a claim with a given prefix. This goes for claim types and values. And the workaround seems easy enough:

builder.Services.AddAuthorization(options =>
{
   // Checking if there is any claim type that starts with a certain prefix
   options.AddPolicy("prefix", policy => policy.RequireAssertion(ctx => ctx.User.HasClaim(claim => claim.Type.StartsWith("prefix"))));
});

It's not quite as terse, but it doesn't seem too onerous.