Custom Authorize attribute without Identity and OWIN

Question

I would like to construct a custom authorization attribute that does not invoke Identity or OWIN. Essentially, the only thing that it should have access to is a request context and the ability to either tell the MVC framework to process to continue to process the request or deny it.

Question Is there a simple way of achieving this in ASP.NET Core 2?

Some ideas My understanding of ASP.NET Core is that it provides a way to customize the request pipeline using different middleware. I have seen that there are specific ones that are used for authentication, but they all seem to be very specific to Identity.

Is it better to to use a different type of filter?

Not really sure what you're looking for as this basically already is the situation (at least partly). The authorization middleware is totally separate from Identity. Technically there's nothing separate from OWIN as that's kind of the underpinnings of ASP.NET Core entirely. However, that's more in Kestrel. — Chris Pratt, May 24 '18 at 13:36
I'm looking for an example of how to create an attribute that inherits from authorizeattribute the same it could be done in ASP.NET MVC (the .NET framework version). — Artem, May 24 '18 at 14:18
That's not really any clearer. I mean simplistically, it's the same as it always has been. You just create a new class, inherit from `AuthorizeAttribute` and override whatever you want. That said, you don't really need to and probably shouldn't do that. ASP.NET Core has policy-based authorization now, which would probably be your best solution: https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.1 — Chris Pratt, May 24 '18 at 15:45
Thanks for the link! I think the main problem is that ASP.NET Core forces users to use this new policy based auth, which may not be applicable in all cases, especially if you have the need of writing custom authentication and authorisation logic. — Artem, May 25 '18 at 07:58
That's what a policy is. It's custom logic. Policy-based auth gives you an easy way to do that without going down inadvisable routes like deriving from AuthorizeAttribute. Also, it's not forced. It's entirely optional. Every component is entirely optional. — Chris Pratt, May 25 '18 at 09:41

score 2 · Answer 1 · answered Jun 18 '18 at 14:25

A little bit late answer, but still.. the "old" way of overriding attributes comes back with the .Net Core 2.0, where in addition to the base class, you have to implement the IAuthorizationFilter interface:

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

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


    public void OnAuthorization(AuthorizationFilterContext context)
    {
        // you can play with the context here 
    }
}

More discussion here

Custom Authorize attribute without Identity and OWIN

1 Answers1