Search code examples
c#asp.net-mvcsecurityaccess-controldocument-management

Document-Based Security in ASP.NET MVC


I already know about User and Role-based security in ASP.NET MVC. But now I need something a little more granular.

Let's say I have a list of documents, some of which the user is authorized for, some not. Each document has a corresponding record in a documents table in a database. Documents can be downloaded for viewing, if the user has security access. Documents can also be added, if you have the role. Each document has an URL, and each document list has an URL.

I would like to security trim the list so that the user only sees those documents for which he is authorized. But I also need to authenticate the URL requests for these lists and documents, since there is nothing preventing a user from bookmarking a document they no longer have access to, or simply typing the URL into the browser.

Is the built-in role-based security model suitable for this, or do I need to create separate, table-based security? Can I put the security in my repository, so that the returned records are already trimmed, or should it be part of the controller? Do I need a security attribute to validate the controller request, or should I just put it in the controller method as the first few lines of code?


Solution

  • @Robert, I think you've already answered your own question when you said you should trim them (before) they reach the view. So in your Business logic, as a preference over the repository, you might want to do a lamda to trim off the excess so to speak.

    Im my opinion I would never return any records to the view that the user wasn't allowed to see. Why increase risk and traffic?

    As for the bookmarks I think there you're going to need to do some business logic preventing them from going to the url when access no longer exists.

    I thought the controller was simply there to service the data to the page and not to have any logic as such so I'd prefer the business layer approach for this one as it does appear to be a business rule.

    That might not be what you had in mind but unless there is a better approach it's the one I would use.