在Spring中保护REST资源的更好方法？

Question

I have a RESTful service that exposes resources like /user/{id}

Now, the user can provide the credentials, get the token and access the resource. However, once authenticated, the user can access the resources for any id .

Meaning, user1 can access the URIs like /user/1 as well as user/2 and so on. I ended up using a Principal in the controller methods and started checking the id of the Principal with the id the user is trying to access.

Further, the user has multiple resources associated with it. Say, user1 owns res1 and res2, user2 owns res3 and res4. These can be accessed via /user/1/res/2 . I need a way where I can prevent /user/1/res/3 as res3 is owned by user1 and not user2.

But I believe that this problem is very common and I am not really convinced with my solution.

Is there a better way to deal with this problem?

Thanks

Answer 1

You should not be exposing resourse /user/{id} at all if you all user can do is access only their own ID. If I understand correctly, just exposing /user is enough, find ID of user from Principal or session etc and return result.

If you really want to do it, you can have custom implementation of @PreAuthorize. Got this code from a blog.

@PreAuthorize("isUsersRes(#id)")
@RequestMapping(method = RequestMethod.GET, value = "/users/{id}")
public UsersfindById(@PathVariable long id) {
return Users.findOne(id);
}

public class CustomMethodSecurityExpressionRoot extends SecurityExpressionRoot implements MethodSecurityExpressionOperations {

public CustomMethodSecurityExpressionRoot(Authentication authentication) {
    super(authentication);
}

And implemenation of isUsersRes

public class CustomMethodSecurityExpressionRoot 
extends SecurityExpressionRoot implements MethodSecurityExpressionOperations {
public boolean isMember(Long OrganizationId) {
 //user logic
}

Check complete blog here

Answer 2

This is a common problem with varied solutions. Also its not a problem related to REST alone. We have had this ever since apps exist. Employee can see his salary slip, leave records, etc but not another employee's. One solution I like the most is 'security in depth'. This idea comes from how I have seen this work in banking systems for decades. This needs to get supported in the DB layer first. You would need a table design like this example (or whatever your app's entity hierarchical structure is):

Organisation
-Dept
--user

And all non-master tables need to have a relation to one of these entities. Example:

Payslip -> user
Leave record -> user
Manager -> dept
HR Manager -> org

etc...

You would need another table to map out the basic access levels (This can get complex if we need to implement different sub access levels)

user1:dept2:org1
user2:dept2:org1

(I have seen some implementations that send this table's info as part of an encrypted access token that is used on every access request if the access has to be sessionless.)

You have not mentioned a framework/language but most languages have a database layer. For example if the DB layer is hibernate-java. There are interceptors ( https://docs.jboss.org/hibernate/core/3.6/javadocs/org/hibernate/Interceptor.html#onPrepareStatement(java.lang.String) ) that can be used to modify the query thats being executed. Every query to DB will go with additional where-clause for these relationship keys. We can get clever with Spring AOP, REST interceptors and a lot of other techniques on top of this basic architecture to enforce this security. Idea will be that DB layer does not return data thats not accessible to the logged in user principal irrespective of what queries higher layer code uses. if this is in place, a REST GET call for

/payslip/user1/Jan-2017

will end up with a 404 and not a 403. Expecting this to be solved by a framework or a superficial set of interceptors is both risky and not future proof. We end up continuously tweaking the interceptors as the url patterns evolve.

Addition to show table examples:

ACL table
user, uid, dept, org
--------------------
jhon, 1  , 1   , 1
mary, 2  , 2   , 1
will, 3  , 2   , 1

Payslip table
--------------
month, net, deductions,..., uid
-------------------------------------
Jan  , 200, 15.5      ,..., 3  
Feb  , 200, 15.5      ,..., 3

Project table
-------------
pname, pstart, pbudget, dept
------------------------------------
mark1, 12/21 , 20000  , 2
markx, 12/31 , 40000  , 2

Answer 3

What you want is user roles and permissions + cross user control. To find out user roles and permissions refer this

Also additionally you may want to cross check their user ID to the resource ID. Since you cannot let user1's resource ID 1 to view by user2, you will need to add userID as part of the resource id ex:- /user/user_id_1. Otherwise we don't have a logical way to separate which resources are applicable to which users.