We have a number of security features blocking access to various OData v4 (Microsoft OData v4 implementation) actions based on user roles and permissions. To some extent it is record-level access rights. These security checks are implemented in controller actions themselves, namely the data is filtered directly in the EF LINQ query filter based SQL joins to user permissions. However, as long as [Queryable(MaxExpansionDepth = 0)] is not applied everywhere (which we don't want) we have found that any user can tack on $expand to any URL and get any related entity he pleases, without going through the security checks of the actions defined for each of the standard entity routes. For example, if /OData/Projects/ is accessible to a user but /OData/Projects(5)/Employees/ to access employees associated with project 5 is not accessible because of security checks applied to that route within the body of the controller action implementation, the user can just access /OData/Projects(5)?$expand=Employees($expand=SalaryInfo).
There doesn't seem to be any way to block this that I've found, other than blocking navigation properties altogether via MaxExpansionDepth.
What would be ideal is if, since the OData EDM already knows about entities and the Web API routes they're associated with, therefore all navigation properties could be set up to be fed through the existing OData Web API controller action for that entity. In other words, it would be ideal if /OData/Projects(5)?expand=Employees($expand=SalaryInfo) was handled by OData itself to "join" to /OData/Employees/ on /OData/Projects(5) and then to /OData/Employees/Salary, using those contoller actions, rather than through a SQL join via EF, just by nature of the fact that the EDM knows that those entities map to those routes. This way we can define our authorization logic in exactly one place (controller actions) while still enjoying the $expand syntax flexibility. Am I hoping for something stupidly unreasonable?
I've seen this solution but then the problem becomes we would have separate definitions of security, unless the definition of security in that solution itself invokes the action, even then it's only a blocker and not a conditional data filter as we have implemented.
If not, we will have to settle for peppering [Queryable(MaxExpansionDepth = 0)] on every single vulnerable API endpoint in our system.
I have a requirement where I need to use role based access to service methods. I have restful services and i use spring-data to interact with MongoDB.
There are some of the restrictions that I have. I deal with a document in DB called "Organization". In each organization, I know who are the Admins. I do not have a repository of users who can access the services.
So the only way I can enforce some access based rules is to check if the logged in user is one of the admin's configured for each organization and then allow the user to access the methods.
Should I think of applying Spring security in this case? Otherwise will a simple check on user against the configured admins in the database document help? Can I make this check at a single point so that I can apply it to service methods based on my use case needs.
Please provide your suggestions / thoughts on how to go about this.
If you use Spring Security your rest methods can take advantage of a passed-in authenticated Principal object (example here) whereupon you can do whatever extra validation desired (such as checking if the admin is good for the given organization requested, etc.) There are many other parameters also available, perhaps allowing for this org checking to be done once and stored in the session object.
I'm using Spring Security which works great to make sure that a user has a certain role before accessing a resource. But now I need to verify something a little different:
`/product/edit/{productId}`
What is the best way to verify that the logged in user "owns" productId? My business mappings handle the relationship (a user has a list of products). I need to verify this product belongs to the user and hence, they can edit it.
I know how to gain access to productId and the logged in user in both the controller and an interceptor. I don't believe this logic belongs in the controller at all. The interceptor seems better but I wondered if Spring Security had an "accepted" way of handling this situation.
Yes, in Spring you can implement this by implementing Access Control Lists. ACL declaration specifies permissions for individual objects per user. Once you have everything setup like acl entries in your database and logic, you can use SpEL and #PostFilter annotation to control the list of objects returned to a user.
Spring Security Documentation
Related:
We have Implemented REST Based Architecture for our ASP.NET MVC3 App.
We are pondering over the architectural decision to implement a custom Authorization for the contracts we are exposing through our service.
e.g. Any valid authenticated user may get access to a particular Method implementation of the contract and might want to access some other user's info (getting a list of items from the data through Stored Proc) , we need to check after we get back this Items list that whether this authenticated User has proper permissions to access this. The permission check is based on a heavy business logic , hence Attribute based authorization might not be helpful in this scenario as only after getting back the data we might decide the access permission check.
Please advice how to implement this security model inside our REST Service.
Since attribute based auth seemingly won't work for you, then you'll need to determine if they fit the role you need:
HttpContext.Current.User.IsInRole()
After that your controller simply returns an HttpUnauthorizedResult which is an ActionResult.
So check your business logic, if they aren't authorized, then return HttpUnauthorizedResult and you are done.
http://msdn.microsoft.com/en-us/library/system.web.mvc.httpunauthorizedresult.httpunauthorizedresult(v=vs.98).aspx
I'm writing a web application with some ACL requirements: a user can make changes to some items, some items may be editable by several users, administrator can edit anything and a manager can edit everything within her organization etc.
I'm using the Play! framework, and by the looks of the Secure module, it seems that the place to put authorization concerns is in the Controllers. However, it seems to me that the authorization issues are part of the business logic, and therefore should be in the model. Furthermore, I'm starting to see duplicated logic in the controllers that I need to refactor out.
On the other hand, adding authorization to the model means that I'd have to have some way of getting the current user from within the model, which doesn't seem right. Alternatively, I could add a "current_user" parameter to every model method, but that seems even worse.
So what is the common practice? Can/should I put authorization code in the model, or keep it in the controller?
I think this is a grey area. One could argue that the user access is part of the mapping between the HTTP world and the Object-Oriented world. This is what the controller is intended for (hence the heavy use of statics), to transform the incoming request, ready to process the business rules on the domain model.
I would suggest that the controller logic is absolutely the right place for controlling the access to the model, especially as this is managed largely at an annotation level, and the authentication is abstracted off to a Security class.
Authorization should neither be part of controller or domain model.
Instead it should be in the service layer.
Controller should just act as dispatcher and delegate between HTTP and application service.
It's the application service where the orchestration takes place. This is the best place for placing authorization.
Suppose user A is authorized to access data from domain X, but not authorized for even a read access for data from domain Y. If authorization is placed in the controller, then user A gets authorized in the controller X, and via the service calls can access data from domain Y, which is not what we expected.
Since domain models communicate with each other on service layer, hence it best to place the authorization on the same level.
In most cases, the security should be one (or more) layer above the Model. Security is a domain on it's own, restricting access to a lower level layer.
I don't think the security should be done at the controller level.
In my opinion, this should look like that:
View -> Controller -> Security -> Model
The security layer could be a façade or a proxy over the model, protecting access, but be transparent to the controller.
However, if the views are to be modified depending on the access rights of the user, some checks might have to happen at the controller level (like setting the value of a CanEdit boolean property on the ViewModel).
I personally really like the way the Play! Secure module handles this (the tutorial is ever-helpful here). If you don't mind using the #Before annotation, it's pretty painless.
I am at this stage and intending to handle this in the following way:
No form validation by JS, instead via HTTPS ajax
An Ajax php class
Form data sent to a model as its data for concrete validation for
common type such as email and password (likely assoc array validation will be reused by other classes so this is definately a model area).
if no error a lookup in a User table for the credentials email /
password credentials passed to a Controller with the authentication
type such as login / signup / password reset
the controller then produces the required output view or sets user logged in session etc
This is based in Laravel but I have my own library as want it independent of laravel and just loosely based for this vital requirement.
The point being that the Model looks up the required credentials as data, then sends to the Controller as it does not care how it should be processed. I think this is the only way to make this area a definitive responsibility between each of the components.
From my personal experience with MVC frameworks I would say:
Model is an object that is representing database table it should be
pure and should not contain any additional logic.
Controller is the place where are made the decisions and other
custom logic, so the authorization should be in the controller. It
could be designed some hook that can check if the user is authorized
or not in all needed places so you wont have a code repetition DRY.
The best way to give permission to user if you are using a typical
REST architecture is to make a token , save it in the databse and on
client side and verify this token on every request. If you are using
web browser app you can use server-side sessions for authorization (
Its much more easier).
So my propose is to keep the authorization logic in the Controller.
I'll use Rails as an example. The authorization library, pundit, places authorization firmly within the "model" domain - this is enforced through their helper methods.
Suppose you have a ShoppingBag model. You might want to create a ShoppingBag
class ShoppingBagController
def create
authorize ShoppingBag.new, current_user
end
end
It works really well if you have a 1-1 mapping between a model and a controller. But what if you need a second controller on the same model? Now you're stuck!
class DiscountedShoppingBagController
def create
authorize ShoppingBag.new, current_user # does not work for us. we want a slightly different authorization, on the same model.
end
end
It's for that reason I dislike pundit, and CanCanCan. Authorization at the controller level, for me, is ideal. Doing so on the model level limits me too much, without any commensurate gain.