Wie erstellen Sie ein benutzerdefiniertes AuthorizeAttribute in ASP.NET Core?

Ich versuche, ein benutzerdefiniertes Berechtigungsattribut in ASP.NET Core zu erstellen. In früheren Versionen war es möglich, zu überschreibenbool AuthorizeCore(HttpContextBase httpContext) . Dies existiert aber nicht mehr in AuthorizeAttribute.

Wie wird derzeit ein benutzerdefiniertes AuthorizeAttribute erstellt?

Was ich versuche zu erreichen: Ich erhalte eine Sitzungs-ID in der Header-Autorisierung. Anhand dieser ID weiß ich, ob eine bestimmte Aktion gültig ist.

Der vom ASP.Net Core-Team empfohlene Ansatz besteht darin, das neue Richtliniendesign zu verwenden, das hier vollständig dokumentiert ist . Die Grundidee des neuen Ansatzes besteht darin, das neue Attribut [Authorize] zu verwenden, um eine "Richtlinie" [Authorize( Policy = "YouNeedToBe18ToDoThis")]zu bestimmen (z. B. wenn die Richtlinie in Startup.cs der Anwendung registriert ist, um einen Codeblock auszuführen (dh sicherzustellen, dass der Benutzer einen Altersanspruch hat) wo das Alter 18 oder älter ist).

Das Richtliniendesign ist eine großartige Ergänzung des Frameworks, und das ASP.Net Security Core-Team sollte für seine Einführung gelobt werden. Das heißt, es ist nicht für alle Fälle gut geeignet. Der Nachteil dieses Ansatzes besteht darin, dass er keine bequeme Lösung für die häufigste Notwendigkeit bietet, einfach zu behaupten, dass ein bestimmter Controller oder eine bestimmte Aktion einen bestimmten Anspruchstyp erfordert. In dem Fall, in dem eine Anwendung möglicherweise über Hunderte von diskreten Berechtigungen für CRUD-Operationen für einzelne REST-Ressourcen verfügt ("CanCreateOrder", "CanReadOrder", "CanUpdateOrder", "CanDeleteOrder" usw.), erfordert der neue Ansatz entweder wiederholte Einzelaufgaben eine Zuordnung zwischen einem Richtliniennamen und einem Anspruchsnamen (zoptions.AddPolicy("CanUpdateOrder", policy => policy.RequireClaim(MyClaimTypes.Permission, "CanUpdateOrder));) oder Schreiben von Code, um diese Registrierungen zur Laufzeit durchzuführen (z. B. alle Anspruchstypen aus einer Datenbank lesen und den oben genannten Aufruf in einer Schleife ausführen). Das Problem bei diesem Ansatz besteht in den meisten Fällen darin, dass kein unnötiger Overhead erforderlich ist.

Während das ASP.Net Core Security-Team empfiehlt, niemals eine eigene Lösung zu erstellen, ist dies in einigen Fällen die umsichtigste Option, um damit zu beginnen.

Das Folgende ist eine Implementierung, die den IAuthorizationFilter verwendet, um eine einfache Möglichkeit zum Ausdrücken einer Anspruchsanforderung für einen bestimmten Controller oder eine bestimmte Aktion bereitzustellen:

public class ClaimRequirementAttribute : TypeFilterAttribute
{
    public ClaimRequirementAttribute(string claimType, string claimValue) : base(typeof(ClaimRequirementFilter))
    {
        Arguments = new object[] {new Claim(claimType, claimValue) };
    }
}

public class ClaimRequirementFilter : IAuthorizationFilter
{
    readonly Claim _claim;

    public ClaimRequirementFilter(Claim claim)
    {
        _claim = claim;
    }

    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var hasClaim = context.HttpContext.User.Claims.Any(c => c.Type == _claim.Type && c.Value == _claim.Value);
        if (!hasClaim)
        {
            context.Result = new ForbidResult();
        }
    }
}


[Route("api/resource")]
public class MyController : Controller
{
    [ClaimRequirement(MyClaimTypes.Permission, "CanReadResource")]
    [HttpGet]
    public IActionResult GetResource()
    {
        return Ok();
    }
}

Ich bin die asp.net-Sicherheitsperson. Lassen Sie mich zunächst entschuldigen, dass noch nichts davon außerhalb des Beispiels oder der Komponententests des Musikgeschäfts dokumentiert ist und alles noch in Bezug auf exponierte APIs verfeinert wird. Eine ausführliche Dokumentation finden Sie hier .

Wir möchten nicht, dass Sie benutzerdefinierte Berechtigungsattribute schreiben. Wenn Sie das tun müssen, haben wir etwas falsch gemacht. Stattdessen sollten Sie die Berechtigung schreiben Anforderungen .

Die Autorisierung wirkt sich auf Identitäten aus. Identitäten werden durch Authentifizierung erstellt.

Sie sagen in Kommentaren, dass Sie eine Sitzungs-ID in einem Header überprüfen möchten. Ihre Sitzungs-ID wäre die Grundlage für die Identität. Wenn Sie das AuthorizeAttribut verwenden möchten, schreiben Sie eine Authentifizierungs-Middleware, um diesen Header in eine authentifizierte zu verwandeln ClaimsPrincipal. Sie würden dies dann innerhalb einer Autorisierungsanforderung überprüfen. Die Autorisierungsanforderungen können so kompliziert sein, wie Sie möchten. Hier ist beispielsweise eine, bei der ein Geburtsdatum für die aktuelle Identität angegeben wird und die autorisiert wird, wenn der Benutzer über 18 Jahre alt ist.

public class Over18Requirement : AuthorizationHandler<Over18Requirement>, IAuthorizationRequirement
{
        public override void Handle(AuthorizationHandlerContext context, Over18Requirement requirement)
        {
            if (!context.User.HasClaim(c => c.Type == ClaimTypes.DateOfBirth))
            {
                context.Fail();
                return;
            }

            var dateOfBirth = Convert.ToDateTime(context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth).Value);
            int age = DateTime.Today.Year - dateOfBirth.Year;
            if (dateOfBirth > DateTime.Today.AddYears(-age))
            {
                age--;
            }

            if (age >= 18)
            {
                context.Succeed(requirement);
            }
            else
            {
                context.Fail();
            }
        }
    }
}

Dann ConfigureServices()würden Sie es in Ihrer Funktion verkabeln

services.AddAuthorization(options =>
{
    options.AddPolicy("Over18", 
        policy => policy.Requirements.Add(new Authorization.Over18Requirement()));
});

Und schließlich wenden Sie es auf einen Controller oder eine Aktionsmethode mit an

[Authorize(Policy = "Over18")]

Es scheint, dass Sie mit ASP.NET Core 2 erneut erben AuthorizeAttributekönnen. Sie müssen lediglich Folgendes implementieren IAuthorizationFilter(oder IAsyncAuthorizationFilter):

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class CustomAuthorizeAttribute : AuthorizeAttribute, IAuthorizationFilter
{
    private readonly string _someFilterParameter;

    public CustomAuthorizeAttribute(string someFilterParameter)
    {
        _someFilterParameter = someFilterParameter;
    }

    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var user = context.HttpContext.User;

        if (!user.Identity.IsAuthenticated)
        {
            // it isn't needed to set unauthorized result 
            // as the base class already requires the user to be authenticated
            // this also makes redirect to a login page work properly
            // context.Result = new UnauthorizedResult();
            return;
        }

        // you can also use registered services
        var someService = context.HttpContext.RequestServices.GetService<ISomeService>();

        var isAuthorized = someService.IsUserAuthorized(user.Identity.Name, _someFilterParameter);
        if (!isAuthorized)
        {
            context.Result = new StatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
            return;
        }
    }
}

Basierend auf Derek Greer GREAT Antwort, habe ich es mit Aufzählungen.

Hier ist ein Beispiel für meinen Code:

public enum PermissionItem
{
    User,
    Product,
    Contact,
    Review,
    Client
}

public enum PermissionAction
{
    Read,
    Create,
}


public class AuthorizeAttribute : TypeFilterAttribute
{
    public AuthorizeAttribute(PermissionItem item, PermissionAction action)
    : base(typeof(AuthorizeActionFilter))
    {
        Arguments = new object[] { item, action };
    }
}

public class AuthorizeActionFilter : IAuthorizationFilter
{
    private readonly PermissionItem _item;
    private readonly PermissionAction _action;
    public AuthorizeActionFilter(PermissionItem item, PermissionAction action)
    {
        _item = item;
        _action = action;
    }
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        bool isAuthorized = MumboJumboFunction(context.HttpContext.User, _item, _action); // :)

        if (!isAuthorized)
        {
            context.Result = new ForbidResult();
        }
    }
}

public class UserController : BaseController
{
    private readonly DbContext _context;

    public UserController( DbContext context) :
        base()
    {
        _logger = logger;
    }

    [Authorize(PermissionItem.User, PermissionAction.Read)]
    public async Task<IActionResult> Index()
    {
        return View(await _context.User.ToListAsync());
    }
}

Sie können Ihren eigenen AuthorizationHandler erstellen, der benutzerdefinierte Attribute auf Ihren Controllern und Aktionen findet, und diese an die HandleRequirementAsync-Methode übergeben.

public abstract class AttributeAuthorizationHandler<TRequirement, TAttribute> : AuthorizationHandler<TRequirement> where TRequirement : IAuthorizationRequirement where TAttribute : Attribute
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, TRequirement requirement)
    {
        var attributes = new List<TAttribute>();

        var action = (context.Resource as AuthorizationFilterContext)?.ActionDescriptor as ControllerActionDescriptor;
        if (action != null)
        {
            attributes.AddRange(GetAttributes(action.ControllerTypeInfo.UnderlyingSystemType));
            attributes.AddRange(GetAttributes(action.MethodInfo));
        }

        return HandleRequirementAsync(context, requirement, attributes);
    }

    protected abstract Task HandleRequirementAsync(AuthorizationHandlerContext context, TRequirement requirement, IEnumerable<TAttribute> attributes);

    private static IEnumerable<TAttribute> GetAttributes(MemberInfo memberInfo)
    {
        return memberInfo.GetCustomAttributes(typeof(TAttribute), false).Cast<TAttribute>();
    }
}

Anschließend können Sie es für alle benutzerdefinierten Attribute verwenden, die Sie für Ihre Controller oder Aktionen benötigen. Zum Beispiel, um Berechtigungsanforderungen hinzuzufügen. Erstellen Sie einfach Ihr benutzerdefiniertes Attribut.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public class PermissionAttribute : AuthorizeAttribute
{
    public string Name { get; }

    public PermissionAttribute(string name) : base("Permission")
    {
        Name = name;
    }
}

Erstellen Sie dann eine Anforderung, die Sie Ihrer Richtlinie hinzufügen möchten

public class PermissionAuthorizationRequirement : IAuthorizationRequirement
{
    //Add any custom requirement properties if you have them
}

Erstellen Sie dann den AuthorizationHandler für Ihr benutzerdefiniertes Attribut und erben Sie den zuvor erstellten AttributeAuthorizationHandler. Es wird eine IEnumerable für alle Ihre benutzerdefinierten Attribute in der HandleRequirementsAsync-Methode übergeben, die von Ihrem Controller und Ihrer Aktion gesammelt wurde.

public class PermissionAuthorizationHandler : AttributeAuthorizationHandler<PermissionAuthorizationRequirement, PermissionAttribute>
{
    protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, PermissionAuthorizationRequirement requirement, IEnumerable<PermissionAttribute> attributes)
    {
        foreach (var permissionAttribute in attributes)
        {
            if (!await AuthorizeAsync(context.User, permissionAttribute.Name))
            {
                return;
            }
        }

        context.Succeed(requirement);
    }

    private Task<bool> AuthorizeAsync(ClaimsPrincipal user, string permission)
    {
        //Implement your custom user permission logic here
    }
}

Fügen Sie schließlich in Ihrer Startup.cs ConfigureServices-Methode Ihren benutzerdefinierten AuthorizationHandler zu den Diensten hinzu und fügen Sie Ihre Richtlinie hinzu.

        services.AddSingleton<IAuthorizationHandler, PermissionAuthorizationHandler>();

        services.AddAuthorization(options =>
        {
            options.AddPolicy("Permission", policyBuilder =>
            {
                policyBuilder.Requirements.Add(new PermissionAuthorizationRequirement());
            });
        });

Jetzt können Sie Ihre Controller und Aktionen einfach mit Ihrem benutzerdefinierten Attribut dekorieren.

[Permission("AccessCustomers")]
public class CustomersController
{
    [Permission("AddCustomer")]
    IActionResult AddCustomer([FromBody] Customer customer)
    {
        //Add customer
    }
}

Was ist der aktuelle Ansatz zum Erstellen eines benutzerdefinierten AuthorizeAttribute?

Einfach: Erstellen Sie keine eigenen AuthorizeAttribute.

Für reine Autorisierungsszenarien (z. B. Einschränkung des Zugriffs nur auf bestimmte Benutzer) wird empfohlen, den neuen Autorisierungsblock zu verwenden: https://github.com/aspnet/MusicStore/blob/1c0aeb08bb1ebd846726232226279bbe001782e1/samples/MusicStore/Startup.cs#L84 -L92

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<AuthorizationOptions>(options =>
        {
            options.AddPolicy("ManageStore", policy => policy.RequireClaim("Action", "ManageStore"));
        });
    }
}

public class StoreController : Controller
{
    [Authorize(Policy = "ManageStore"), HttpGet]
    public async Task<IActionResult> Manage() { ... }
}

Für die Authentifizierung wird am besten auf Middleware-Ebene gehandhabt.

Was versuchst du genau zu erreichen?

Wenn jemand nur ein Inhaber-Token in der Autorisierungsphase anhand der aktuellen Sicherheitspraktiken validieren möchte, können Sie

Fügen Sie dies Ihren Startup / ConfigureServices hinzu

    services.AddSingleton<IAuthorizationHandler, BearerAuthorizationHandler>();
    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer();

    services.AddAuthorization(options => options.AddPolicy("Bearer",
        policy => policy.AddRequirements(new BearerRequirement())
        )
    );

und das in deiner Codebasis,

public class BearerRequirement : IAuthorizationRequirement
{
    public async Task<bool> IsTokenValid(SomeValidationContext context, string token)
    {
        // here you can check if the token received is valid 
        return true;
    }
}

public class BearerAuthorizationHandler : AuthorizationHandler<BearerRequirement> 
{

    public BearerAuthorizationHandler(SomeValidationContext thatYouCanInject)
    {
       ...
    }

    protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, BearerRequirement requirement)
    {
        var authFilterCtx = (Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext)context.Resource;
        string authHeader = authFilterCtx.HttpContext.Request.Headers["Authorization"];
        if (authHeader != null && authHeader.Contains("Bearer"))
        {
            var token = authHeader.Replace("Bearer ", string.Empty);
            if (await requirement.IsTokenValid(thatYouCanInject, token))
            {
                context.Succeed(requirement);
            }
        }
    }
}

Wenn der Code nicht erreicht context.Succeed(...)wird, schlägt er trotzdem fehl (401).

Und dann können Sie in Ihren Controllern verwenden

 [Authorize(Policy = "Bearer", AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]

Der moderne Weg ist AuthenticationHandlers

in startup.cs hinzufügen

services.AddAuthentication("BasicAuthentication").AddScheme<AuthenticationSchemeOptions, BasicAuthenticationHandler>("BasicAuthentication", null);

public class BasicAuthenticationHandler : AuthenticationHandler<AuthenticationSchemeOptions>
    {
        private readonly IUserService _userService;

        public BasicAuthenticationHandler(
            IOptionsMonitor<AuthenticationSchemeOptions> options,
            ILoggerFactory logger,
            UrlEncoder encoder,
            ISystemClock clock,
            IUserService userService)
            : base(options, logger, encoder, clock)
        {
            _userService = userService;
        }

        protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
        {
            if (!Request.Headers.ContainsKey("Authorization"))
                return AuthenticateResult.Fail("Missing Authorization Header");

            User user = null;
            try
            {
                var authHeader = AuthenticationHeaderValue.Parse(Request.Headers["Authorization"]);
                var credentialBytes = Convert.FromBase64String(authHeader.Parameter);
                var credentials = Encoding.UTF8.GetString(credentialBytes).Split(new[] { ':' }, 2);
                var username = credentials[0];
                var password = credentials[1];
                user = await _userService.Authenticate(username, password);
            }
            catch
            {
                return AuthenticateResult.Fail("Invalid Authorization Header");
            }

            if (user == null)
                return AuthenticateResult.Fail("Invalid User-name or Password");

            var claims = new[] {
                new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
                new Claim(ClaimTypes.Name, user.Username),
            };
            var identity = new ClaimsIdentity(claims, Scheme.Name);
            var principal = new ClaimsPrincipal(identity);
            var ticket = new AuthenticationTicket(principal, Scheme.Name);

            return AuthenticateResult.Success(ticket);
        }
    }

IUserService ist ein Dienst, den Sie erstellen, wenn Sie Benutzername und Kennwort haben. Im Grunde gibt es eine Benutzerklasse zurück, auf die Sie Ihre Ansprüche abbilden.

var claims = new[] {
                new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
                new Claim(ClaimTypes.Name, user.Username),
            }; 

Dann können Sie diese Ansprüche abfragen und alle Daten, die Sie zugeordnet haben, es gibt einige, werfen Sie einen Blick auf die ClaimTypes-Klasse

Sie können dies in einer Erweiterungsmethode verwenden, um eine der Zuordnungen abzurufen

public int? GetUserId()
{
   if (context.User.Identity.IsAuthenticated)
    {
       var id=context.User.FindFirst(ClaimTypes.NameIdentifier);
       if (!(id is null) && int.TryParse(id.Value, out var userId))
            return userId;
     }
      return new Nullable<int>();
 }

Dieser neue Weg ist meiner Meinung nach besser als

public class BasicAuthenticationAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.Headers.Authorization != null)
        {
            var authToken = actionContext.Request.Headers.Authorization.Parameter;
            // decoding authToken we get decode value in 'Username:Password' format
            var decodeauthToken = System.Text.Encoding.UTF8.GetString(Convert.FromBase64String(authToken));
            // spliting decodeauthToken using ':'
            var arrUserNameandPassword = decodeauthToken.Split(':');
            // at 0th postion of array we get username and at 1st we get password
            if (IsAuthorizedUser(arrUserNameandPassword[0], arrUserNameandPassword[1]))
            {
                // setting current principle
                Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity(arrUserNameandPassword[0]), null);
            }
            else
            {
                actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
            }
        }
        else
        {
            actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
        }
    }

    public static bool IsAuthorizedUser(string Username, string Password)
    {
        // In this method we can handle our database logic here...
        return Username.Equals("test") && Password == "test";
    }
}

Zum jetzigen Zeitpunkt glaube ich, dass dies mit der IClaimsTransformation-Schnittstelle in asp.net Core 2 und höher erreicht werden kann. Ich habe gerade einen Proof of Concept implementiert, der gemeinsam genutzt werden kann, um hier zu posten.

public class PrivilegesToClaimsTransformer : IClaimsTransformation
{
    private readonly IPrivilegeProvider privilegeProvider;
    public const string DidItClaim = "http://foo.bar/privileges/resolved";

    public PrivilegesToClaimsTransformer(IPrivilegeProvider privilegeProvider)
    {
        this.privilegeProvider = privilegeProvider;
    }

    public async Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
    {
        if (principal.Identity is ClaimsIdentity claimer)
        {
            if (claimer.HasClaim(DidItClaim, bool.TrueString))
            {
                return principal;
            }

            var privileges = await this.privilegeProvider.GetPrivileges( ... );
            claimer.AddClaim(new Claim(DidItClaim, bool.TrueString));

            foreach (var privilegeAsRole in privileges)
            {
                claimer.AddClaim(new Claim(ClaimTypes.Role /*"http://schemas.microsoft.com/ws/2008/06/identity/claims/role" */, privilegeAsRole));
            }
        }

        return principal;
    }
}

Um dies in Ihrem Controller zu verwenden, fügen Sie einfach eine entsprechende [Authorize(Roles="whatever")]Methode zu Ihren Methoden hinzu.

[HttpGet]
[Route("poc")]
[Authorize(Roles = "plugh,blast")]
public JsonResult PocAuthorization()
{
    var result = Json(new
    {
        when = DateTime.UtcNow,
    });

    result.StatusCode = (int)HttpStatusCode.OK;

    return result;
}

In unserem Fall enthält jede Anforderung einen Autorisierungsheader, der ein JWT ist. Dies ist der Prototyp, und ich glaube, wir werden nächste Woche in unserem Produktionssystem etwas sehr Nahes tun.

Zukünftige Wähler berücksichtigen das Datum des Schreibens, wenn Sie abstimmen. Ab heute works on my machine.möchten Sie wahrscheinlich mehr Fehlerbehandlung und Protokollierung Ihrer Implementierung.

Zur Autorisierung in unserer App. Wir mussten einen Dienst basierend auf den im Berechtigungsattribut übergebenen Parametern aufrufen.

Wenn wir beispielsweise überprüfen möchten, ob der angemeldete Arzt Patiententermine anzeigen kann, übergeben wir "View_Appointment" an das benutzerdefinierte Berechtigungsattribut und überprüfen dieses Recht im DB-Service und basierend auf den Ergebnissen, die wir autorisieren. Hier ist der Code für dieses Szenario:

    public class PatientAuthorizeAttribute : TypeFilterAttribute
    {
    public PatientAuthorizeAttribute(params PatientAccessRights[] right) : base(typeof(AuthFilter)) //PatientAccessRights is an enum
    {
        Arguments = new object[] { right };
    }

    private class AuthFilter : IActionFilter
    {
        PatientAccessRights[] right;

        IAuthService authService;

        public AuthFilter(IAuthService authService, PatientAccessRights[] right)
        {
            this.right = right;
            this.authService = authService;
        }

        public void OnActionExecuted(ActionExecutedContext context)
        {
        }

        public void OnActionExecuting(ActionExecutingContext context)
        {
            var allparameters = context.ActionArguments.Values;
            if (allparameters.Count() == 1)
            {
                var param = allparameters.First();
                if (typeof(IPatientRequest).IsAssignableFrom(param.GetType()))
                {
                    IPatientRequest patientRequestInfo = (IPatientRequest)param;
                    PatientAccessRequest userAccessRequest = new PatientAccessRequest();
                    userAccessRequest.Rights = right;
                    userAccessRequest.MemberID = patientRequestInfo.PatientID;
                    var result = authService.CheckUserPatientAccess(userAccessRequest).Result; //this calls DB service to check from DB
                    if (result.Status == ReturnType.Failure)
                    {
                        //TODO: return apirepsonse
                        context.Result = new StatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
                    }
                }
                else
                {
                    throw new AppSystemException("PatientAuthorizeAttribute not supported");
                }
            }
            else
            {
                throw new AppSystemException("PatientAuthorizeAttribute not supported");
            }
        }
    }
}

Und bei API-Aktionen verwenden wir es folgendermaßen:

    [PatientAuthorize(PatientAccessRights.PATIENT_VIEW_APPOINTMENTS)] //this is enum, we can pass multiple
    [HttpPost]
    public SomeReturnType ViewAppointments()
    {

    }

Die akzeptierte Antwort ( https://stackoverflow.com/a/41348219/4974715 ) ist nicht realistisch wartbar oder geeignet, da "CanReadResource" als Anspruch verwendet wird (sollte aber im Wesentlichen eine Richtlinie in der Realität sein, IMO). Der Ansatz bei der Antwort ist in der Art und Weise, wie er verwendet wurde, nicht in Ordnung. Wenn für eine Aktionsmethode viele verschiedene Anspruchseinstellungen erforderlich sind, müssten Sie mit dieser Antwort wiederholt so etwas wie ...

[ClaimRequirement(MyClaimTypes.Permission, "CanReadResource")] 
[ClaimRequirement(MyClaimTypes.AnotherPermision, "AnotherClaimVaue")]
//and etc. on a single action.

Stellen Sie sich also vor, wie viel Codierung das kosten würde. Im Idealfall sollte "CanReadResource" eine Richtlinie sein, die viele Ansprüche verwendet, um zu bestimmen, ob ein Benutzer eine Ressource lesen kann.

Was ich tue, ist, dass ich meine Richtlinien als Aufzählung erstelle und dann die Anforderungen wie folgt durchlaufe und einrichte ...

services.AddAuthorization(authorizationOptions =>
        {
            foreach (var policyString in Enum.GetNames(typeof(Enumerations.Security.Policy)))
            {
                authorizationOptions.AddPolicy(
                    policyString,
                    authorizationPolicyBuilder => authorizationPolicyBuilder.Requirements.Add(new DefaultAuthorizationRequirement((Enumerations.Security.Policy)Enum.Parse(typeof(Enumerations.Security.Policy), policyWrtString), DateTime.UtcNow)));

      /* Note that thisn does not stop you from 
          configuring policies directly against a username, claims, roles, etc. You can do the usual.
     */
            }
        }); 

Die DefaultAuthorizationRequirement-Klasse sieht aus wie ...

public class DefaultAuthorizationRequirement : IAuthorizationRequirement
{
    public Enumerations.Security.Policy Policy {get; set;} //This is a mere enumeration whose code is not shown.
    public DateTime DateTimeOfSetup {get; set;} //Just in case you have to know when the app started up. And you may want to log out a user if their profile was modified after this date-time, etc.
}

public class DefaultAuthorizationHandler : AuthorizationHandler<DefaultAuthorizationRequirement>
{
    private IAServiceToUse _aServiceToUse;

    public DefaultAuthorizationHandler(
        IAServiceToUse aServiceToUse
        )
    {
        _aServiceToUse = aServiceToUse;
    }

    protected async override Task HandleRequirementAsync(AuthorizationHandlerContext context, DefaultAuthorizationRequirement requirement)
    {
        /*Here, you can quickly check a data source or Web API or etc. 
           to know the latest date-time of the user's profile modification...
        */
        if (_aServiceToUse.GetDateTimeOfLatestUserProfileModication > requirement.DateTimeOfSetup)
        {
            context.Fail(); /*Because any modifications to user information, 
            e.g. if the user used another browser or if by Admin modification, 
            the claims of the user in this session cannot be guaranteed to be reliable.
            */
            return;
        }

        bool shouldSucceed = false; //This should first be false, because context.Succeed(...) has to only be called if the requirement specifically succeeds.

        bool shouldFail = false; /*This should first be false, because context.Fail() 
        doesn't have to be called if there's no security breach.
        */

        // You can do anything.
        await doAnythingAsync();

       /*You can get the user's claims... 
          ALSO, note that if you have a way to priorly map users or users with certain claims 
          to particular policies, add those policies as claims of the user for the sake of ease. 
          BUT policies that require dynamic code (e.g. checking for age range) would have to be 
          coded in the switch-case below to determine stuff.
       */

        var claims = context.User.Claims;

        // You can, of course, get the policy that was hit...
        var policy = requirement.Policy

        //You can use a switch case to determine what policy to deal with here...
        switch (policy)
        {
            case Enumerations.Security.Policy.CanReadResource:
                 /*Do stuff with the claims and change the 
                     value of shouldSucceed and/or shouldFail.
                */
                 break;
            case Enumerations.Security.Policy.AnotherPolicy:
                 /*Do stuff with the claims and change the 
                    value of shouldSucceed and/or shouldFail.
                 */
                 break;
                // Other policies too.

            default:
                 throw new NotImplementedException();
        }

        /* Note that the following conditions are 
            so because failure and success in a requirement handler 
            are not mutually exclusive. They demand certainty.
        */

        if (shouldFail)
        {
            context.Fail(); /*Check the docs on this method to 
            see its implications.
            */
        }                

        if (shouldSucceed)
        {
            context.Succeed(requirement); 
        } 
     }
}

Beachten Sie, dass der obige Code auch die Vorabzuordnung eines Benutzers zu einer Richtlinie in Ihrem Datenspeicher ermöglichen kann. Wenn Sie also Ansprüche für den Benutzer erstellen, rufen Sie im Grunde genommen die Richtlinien ab, die dem Benutzer direkt oder indirekt vorab zugeordnet wurden (z. B. weil der Benutzer einen bestimmten Anspruchswert hat und dieser Anspruchswert identifiziert und einer Richtlinie zugeordnet wurde, z dass es eine automatische Zuordnung für Benutzer bietet, die auch diesen Anspruchswert haben) und die Richtlinien als Ansprüche eintragen, sodass Sie im Autorisierungshandler einfach überprüfen können, ob die Ansprüche des Benutzers eine Anforderung enthalten. Richtlinie als Wert eines Anspruchselements in ihrem Ansprüche. Dies dient dazu, eine Richtlinienanforderung statisch zu erfüllen, z. B. ist die Anforderung "Vorname" recht statisch. Damit,

[Authorize(Policy = nameof(Enumerations.Security.Policy.ViewRecord))] 

Bei einer dynamischen Anforderung kann es sich um die Überprüfung des Altersbereichs usw. handeln, und Richtlinien, die solche Anforderungen verwenden, können Benutzern nicht vorab zugeordnet werden.

Ein Beispiel für die dynamische Überprüfung von Richtlinienansprüchen (z. B. um zu überprüfen, ob ein Benutzer älter als 18 Jahre ist) finden Sie bereits in der Antwort von @blowdart ( https://stackoverflow.com/a/31465227/4974715 ).

PS: Ich habe das auf meinem Handy eingegeben. Verzeihen Sie Tippfehler und fehlende Formatierung.