CODEWITHSUNDEEP
securityrestauthorizationjax-rsglassfish-3
Xiangyu
Xiangyu

Reputation: 322

JAX-RS, how to prevent user A from accessing user B's restful resource

I'm using JAX-RS on Glassfish to implement a set of resources, which can be accessed only by specific users.

Consider two users, userA and userB, both registered in my website.

  1. userA created its own resource http://{localhost}/service/user/A;
  2. userB created its own resource http://{localhost}/service/user/B;

Then Glassfish's default security implementation was configured as:

  1. User Role can access /services/user/*
  2. userA and userB are both in User Role.

So when logged in, both userA and userB can access to /service/user/A and /service/user/B.

Now the question, Is it possible that

and at the same time

I think I must have missed something, because this is a common need I believe. Can anyone help?

Upvotes: 8

Views: 854

Answers (2)

Xiangyu
Xiangyu

Reputation: 322

After searching around, it seems it is not trivial to solve the problem above using the JAX-RS and JAAS.

So I decide to take a look at OAuth, to see if authorization could be easily handled.

After hours reading I started to realize what Olivier was talking about. What I wanted is to bind user identity to the URI. But JAAS or OAuth is really designed to solve other problems.

  1. JAAS, or Role based authentication system is designed to authorize a set of users to access a set of URIs. It's like a room full of toys, once a user plays a roommate ROLE, this user has the key to the room, then he can play with every toy in the room or even destroy all of them. If you want to label each toy with a user's name and stop them from playing with other people's toy, you need to implement the logic outside of JAAS.

  2. OAuth, even worse. It is not even related to binding between user and URI. It is dedicated on letting a 3rd party valet software using your data with limited access. Consider the room-toy story about JAAS, you want the window in the room be opened, but you don't have time for this. So you hired a valet, and made a valet key for him to access the room, open the window, and at the same time, stay away from the toys. The magic part about OAuth is, the valet is given just enough resource to complete master's assignment, and more importantly, the room knows whom sent the valet by recognizing the valet key.

Now from a developer's view, you may ask why the valet can access the window but not the toys; in other words, how to let the 3rd party software access some URI but not other URIs? This is not handled by OAuth. OAuth only tells you Oh, this is Bob's valet, and for everything else, you are on your own.

It is not totally a bad thing about OAuth, it gives you the opportunity to decide what ROLE this valet has, or which URI can this kind of valet access, or what resources can Bob's valet access, etc.

Hope this would help anyone reading save some time. And please don't blame me about the poor story, I struggled 1 hour to make the story simpler. :)

Upvotes: 0

Olivier Liechti
Olivier Liechti

Reputation: 3188

That is something that you have to implement at the application level. The application server has no way to know about your security policy, which could be quite sophisticated. You could do it yourself (adding logic in User resource), and that might be the right approach if your security policy is simple. Otherwise, you should look at Spring Security, which can be integrated with JAX-RS. That will give you a lot of flexibility.

Upvotes: 2

Related Questions