Search code examples
c#asp.netasp.net-mvcsecurityasp.net-identity-2

Validating user rights when invoking controller method in ASP.NET MVC


I'm working on a project where users can log in and create as many number of "work projects" as they like, which are tied to their account Id. We're using OWIN and ASP.NET Identity 2.1.

All the MVC controller actions that respond to HTTP POST requests require the WorkProjectId to be passed in as a HTTP header. The logged in user should only ever be able to interact with WorkProjects that are associated with their login. This presents an important security consideration: is it best practice to interrogate what WorkProjectId are associated with the currently logged in user at the time the controller action is invoked, perhaps by using a custom attribute?

E.g.

[EnsureUserIsAllowedToDoAnythingToThisWPID]
public async Task UpdateWorkProjectTitle(ViewModel vm) {
 ...
}

Because the user can create as many WorkProjects as they see fit, I don't think I can do this with Claims based security. As far as I understand, if WorkProjectIds were somehow stored as Claims, if they were modified it would necessitate logging the user in and out whenever that happened ... which is obviously not acceptable.

So, to achieve what I need, is it "wrong" to store the Ids the logged in user has access to in session state? I've been burned very badly in the past on other projects with session state abuse (read: far too much data being serialised into session state) bringing the web servers to their knees due. I'd prefer to avoid it if there are equally simple approaches.

Thanks


Solution

  • Why not just add/remove claims for current user? On controller side via UserManager.AddClaim by pasting in logged-in-user id and desired Claim object (i.e. id of workProject?). As far as I know, storing user data (i.e. allowed WorkProjectIds) in cookies is preferable. And your custom authorize attribute will check if requested WorkProject is allowed for current user:

    [AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Method,
        Inherited = true, AllowMultiple = true)]
    public class CustomAuthorizeAttribute : AuthorizeAttribute
    {
        private string _url; // path to action, also you can get it from request
        private Operations _operation; // user requested action (CRUD? or administer, execute, etc.)
    
        // example of usage as attribute [CustomAuthAttrib("some string", Operations.Create)]
        public CustomAuthorizeAttribute(string url, Operations operation)
        {
            _url = url;
            _operation = operation;
        }
    
        protected override bool AuthorizeCore(HttpContextBase httpContext)
        {
            // any httpContext.Request... operations
            return base.AuthorizeCore(httpContext);
        }
    }
    

    Here is my some raw listing, currently I'm facing somewhat similar problem. And, to access claims here probably you will need some extension methods that came within OWIN/Katana and/or ASP.NET Identity framework