I have a problem that each user can retrieve other users data from URL.
For instance, I have a rest api like this:
#GetMapping("/getFindByPersonId/{perId}")
#Timed
public List<ComboVahedAmoozeshi> getFindBySkhsIdCombo(#PathVariable Long perId){
return comboVahedAmoozeshiRepository.getFindBySkhsIdCombo(perId);
}
After authorization, each user can change id and get other users data like the image below:
Is there any suggestion to restrict each user to don`t have access to call the method? Or Jhipster have any options to use UUId to hide id?
Thanks from #atomferede for the right answer. I have to add jhi_user_id in other entities and used #postfilter annotation to limit user's access to data.
Although, maybe it`s a good idea to have this option in jhipster generator to enhance the security level and faster implementation.
Related
I have a Spring Data REST service with a single #Entity and Repository. When I run
$ curl localhost:8080/api
I get all the data stored in my repository and it works as expected. I also have a small React front end and I display that data there.
My question is: Where should I filter the data? For example maybe I want all the entries with id > 10. Should I just filter the response in my front end or should I make the REST call in such a way that it returns just the required entries?
If I should do the latter, then how?
Thanks.
Filter in the backend or - more specifically - with the database query.
The database is optimized for those operations. Thus, you can reduce the data transmitted from the backend to the frontend and reduce the load on the frontend since only data that is requested by the user will be processed by the frontend.
Another benefit is that if you have multiple frontends (e.g. website & mobile app), you have to implement filter functionality only once (in the backend) instead of twice (in each client)
If it is always the case, why would you put extra burden on front-end shoulders to filter the results all the time?
Implement a new method which returns the desired results(e.g id > 10) and annotate it with #Query and provide JPQL or native query inside it
#Query("SELECT c FROM Customer c WHERE c.id > 10")
Collection<Customer> findAllActiveCustomers();
However, if you choose native query do not forget to put nativeQuery = true inside #Query
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
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
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
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.
I've been trying to integrate my application with facebook for a very long time, but I can't find any good example how to do this without storing user connections. I know that there is project called spring-social and I can integrate it by implementing SocialConfigurer methods , but it requires UsersConnectionRepository, which is a bad idea.
I also don't want to redirect my requests since I already have facebook access id ( it's passed from other application ). I simply want to log in and create user in my db ( if didn't exist before )
How can I do this ?
Ideally I would like to have something like this :
facebookService.getUserDetails(facebookAccessId)
facebookService.getPhotos(facebookAccessId, ... )
No sessions etc
So you just want to create a new user in your DB if it does not exist right? And no open connection? Then you can use JPA (When you are working with Java) or Entity-Framework (.NET).
In JPA you can work in combination with objectdb. http://www.objectdb.com/
It's as simple as it sounds. (You can handle all with JPQL (SQL for JPA))
When you are also working with Maven you can implement JPA & Objectdb with this code: http://m2.objectdb.com/
I am doing NTLM/Kerberos SSO using com.sun.jna.platform.win32.Sspi, com.sun.jna.platform.win32.Secur32 and com.sun.jna.platform.win32.AdvapiUtils to actually authenticate the user against the AD and retrieve its username. This works perfectly for both domain and non-domain users. As a next step I would like to retrieve a custom user property from the AD, e.g. email. Unfortunately, the com.sun.jna.platform.win32.Advapi32Util.Account class has only fqn, sid and groups properties. Is it possible using the native interfaces listed above to retrieve other properties as well?
I can't use LDAP because of a number of constraints, so I am looking for a work around.
In a JPA app I have a scenario in which the app is to
list all accounts the given user is authorized to withdraw from
I have the Account entity and a many-to-many table that lists what authorizations each user has on each account – to implement the above scenario, the app currently just inner-joins the two tables – which is quite quick.
Now, I was planning to add an explicit authorization layer (based on apache shiro / spring security / other) to insulate authorization-related logic from the rest of the code, but...
There are some 10k Accounts in the database and the "average" user is granted "deposit" on all of them, "view" on one half of them and "withraw" on just a few.
Does any security framework allow to implement this scenario efficiently?
Ie: is any of them able to "decorate" a JPA query of the type "select a from Account a" (or the equivalent SQL) and thus get the list of accounts without loading all user grants from the database, and by all means, without having to retrieve all accounts?)
Have a look at Apache Shiro.
It allows you to pull in the User authorization once and cache it for the duration of the session. In addition, if all users can VIEW all ACCOUNTS then you wouldn't need to explicitly define this which would significantly reduce the overhead.
If your solution requires realtime access handlers Shiro has a way to reset the Permissions dynamically during runtime too.
Shiro allows you to implement a typical RBAC and define permissions like this:
domain:action:instance
So in your case permissions might look like this for a user:
account:deposit:* // deposit all accounts
account:view:1111
account:view:2222
account:view:3333 // view on these accounts
account:withdraw:5555
account:withdraw:6666 // withdraw on these accounts
In code you can then do something like this:
if (SecurityUtils.getSubject().isPermitted("account:withdraw:"+account.getAccountNumber() ) {
// handle withdraw
}
Shiro also has annotation driven permissions for additional abstraction.
EDIT
The Shiro permissions is the end result, not where you start. I used a set of tables representing mappings of the user-to-role and role-to-permission along with other mappings to instance. After AuthN its usually a simple set of queries indexed by the User PK to build up the data structures needed to render the permissions.
I have a hope that this is one of the possibilities to implement your requirement with Spring-Security.
Write custom org.springframework.security.acls.Permission like
ViewAccount,DepositToAccount,WithDrawFromAccount
Write custom
org.springframework.security.access.PermissionEvaluator Override
hasPermission(Authentication userAuthentication,Object
accountObject,Object oneOfThePermission) to check if the user has
the defined permission on the accountObject
Get reference to JPA
EntityManager in your custom evaluator and cross check/verify in DB
with user_id,permission_id,account_id
If the user is 'root' you can
staight away return true for hasPermission without verifying with
DB.
Annotate your service calls with
#PreAuthorize("isAuthenticated() and hasPermission(#accountArgument,
'respectivePermission')")
Refer link for custom implementations of Permission & PermissionEvaluator
If you are using EclipseLink there are a few features for this,
one is the #AdditionalCriteria annotation that allow a filter to be applied to all queries for a class,
http://www.eclipse.org/eclipselink/documentation/2.4/jpa/extensions/a_additionalcriteria.htm#additionalcriteria
another is EclipseLink's support for Oracle VPD (row level security in the database),
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Auditing
and finally EclipseLink supports SessionEvents that can allow filter to be appended to any query execution,
http://www.eclipse.org/eclipselink/api/2.4/org/eclipse/persistence/sessions/SessionEventAdapter.html#preExecuteQuery%28org.eclipse.persistence.sessions.SessionEvent%29