Remove AuthorizationFilterAttribute

[Tratcher]

RE: aspnet/Security#720 (comment)

This regressed at some point. Authorization failures should result in a challenge. The auth middleware will take over and decide what to do with it.
@blowdart @HaoK

Update
Remove AuthorizationFilterAttribute as we do not want users to easily create their own authorization implementation. They should instead use authorization policies and requirements(IAuthorizationRequirement) to enforce authorization.

[blowdart]

What will ChallengeResult end up with if there's no auth middleware?

[Tratcher]

An error saying nobody accepted the challenge. [Authorize] without auth providers is nonsensical.

[rynowak]

Authorize requires an auth policy now, so presumably a configuration without providers would have failed earlier right?

[kevinchalet]

Authorization failures should result in a challenge. The auth middleware will take over and decide what to do with it.

IMHO, this design has always been absolutely evil and semantically "nonsensical". The only place where we know exactly why authorization failed (not authenticated?, lack of permissions?) is in the authorization service. Taking such a decision at the authentication middleware level (by trying to determine whether AuthenticateAsync returned a principal or not) is just wrong.

A while ago, I designed a prototype moving the unauthorized/forbidden decision to the authorization service and introducting an AuthorizationResult determining why the authorization process failed: https://github.com/PinpointTownes/Security/commit/7ac1a2515015a98dc6f4919f28baa9db33beb50a

[rynowak]

Do we need to provide AuthorizationFilterAttribute as a base-class? IMO we shouldn't make it easy to replace the auth system.