• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

preventing other users from accessing a user specific endpoint

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you have a RESTful service that exposes an endpoint called /api/v1/users/{id}, you presumably don't want users who have different user ids from accessing each other's user records even though they have the same role in the system, user.  I was trying to find tutorials about this, but I am not sure what the name of this is.  What should I look up?

Thanks,
Rob
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think putting the user ID in the URL is really a good idea. Obviously, anyone could use any ID unless further checks were needed.

What would be more appropriate would be to authenticate the user, receive an authorization token, and have the application code obtain the user ID based on the authorization token.

Of course, the ReST traffic to obtain and use the token need to be encrypted (HTTPS), plus the token itself should be generated in such a way that no one could guess what token goes with which user.

The non-ReST equivalent of this for JEE is the jsessionid token, which is returned as a cookie or via URL rewriting. The jsessionid is essentially randomly-generated and serves only as a key to find the user's HttpSession in a Map internal to the server. Further, the jsessionid is bounced back and forth on each request/response, and can be replaced (on a response) with a completely different jsessionid at any time, simply re-filing the HttpSession under the new jsessionid. Webapp servers can do that at any time, which is why you should never cache a jsessionid or use it in webapp logic.

Doing it in ReST requires a similar strategy, but since by definition, ReST has no HttpSession, you have to handle the mechanisms yourself in a ReST-friendly way.

 
Robert Dennett
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, supposing you had an authenticated user, how do you make sure that they're only accessing the resources they're authorized to see?  For example, let's say I want to define an endpoint to return a customer's order.  I don't want any other authorized user (unless they have an admin role) to be able to access that order.  What do you call that?
 
Marshal
Posts: 4501
572
VSCode Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could just put a guard at the beginning of your handle which verifies that the user is authorized, and if not, throws an exception.

For example:
 
Robert Dennett
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ron McLeod wrote:You could just put a guard at the beginning of your handle which verifies that the user is authorized, and if not, throws an exception.

For example:



Would that be the standard way to handle it?  Is there a standard way to handle it?  If so, does it have a name?
 
Marshal
Posts: 8857
637
Mac OS X VI Editor BSD Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robert Dennett wrote:Would that be the standard way to handle it?  Is there a standard way to handle it?


Well, that's a difficult question.

What we are talking here is an access control really.

Let's ignore at the moment whether that's a standard way of doing it.

What about the salesman, do they need to be able to access their customers orders? If yes, what's the plan then?

For example an endpoint you are talking about may require just to check whether a specific user can view a resource, however, there might be an endpoint to delete order from the system, should the same user who created order should also be able delete it based on the fact that user id matches that on the order? It depends. If order has been placed already, probably not.

So you may want to have some more flexibility there, i.e. to control based on the role + resource level access.

Spring has PreAuthorize annotation for which you'd provide your implementation, which I think would be closer to what you call a standard, because you would not want to add those checks to each and every controller, but rather have it in one place and act appropriately based on arguments passed to PreAuthorize check.

You can start your research here if that rings the bell: https://docs.spring.io/spring-security/reference/servlet/authorization/expression-based.html#_access_control_using_preauthorize_and_postauthorize




 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robert Dennett wrote:Well, supposing you had an authenticated user, how do you make sure that they're only accessing the resources they're authorized to see?  For example, let's say I want to define an endpoint to return a customer's order.  I don't want any other authorized user (unless they have an admin role) to be able to access that order.  What do you call that?



I call that "access control". And generally, that's going to be determined by application logic. In other words, you write the app so that only authorized users can access the data and what level of access each authorized user is permitted. Authorization can be based on user ID or on whether they have been assigned a specific security role.

Security frameworks are relatively coarse-grained and intended primarily to ensure that a user cannot invoke protected URLs without first authenticating themselves and then passing authorization screening (where assigned). They're not intended to second-guess how applications can interact with data.

Non-web systems can restrict user access to selected tables/functions and (sometimes) records, but that's done using a distinct userid role for every database connection. Webapps are normally using a connection pool and the userid/role(s) that that connection has must necessarily be the greatest common denominator of any access that any application component might need . A reason why I prefer to make user-account registration and editing be in a separate webapp than the app that is secured by those accounts. That allows a more secure connection definition for the app's database connection pool than for the registration/editing app'. And, for that matter, can constraint the registration app's connection from accessing the business data.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The concept you're describing is called "resource-level authorization" or "resource-based access control." This is a common security concern in RESTful APIs, where you need to ensure that only authorized users can access their own data.

To implement this in your API, you will typically use a combination of authentication and authorization mechanisms. Authentication verifies the identity of the user, while authorization determines what actions they are allowed to perform. In the case of resource-level authorization, you would use the user's ID to determine whether they have permission to access a specific resource.

One common approach to implementing resource-level authorization in RESTful APIs is to use JSON Web Tokens (JWTs) to authenticate and authorize users. With JWTs, you can include user-specific information, such as the user ID, in the token itself. Then, when a user makes a request to the /api/v1/users/{id} endpoint, you can check the user ID in the JWT against the ID in the URL to ensure that the user is authorized to access that resource.

To learn more about resource-level authorization and how to implement it in your RESTful API, you can look for tutorials or resources on topics such as JWT authentication, token-based authentication, or OAuth 2.0 https://tech-stack.com/blog/what-is-an-api/
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic