How to control user access to REST resources?

In a Java EE application, there are users (user) each user can create documents (Document)

Access to documents is via JAX-RS.

Before the user will get access to the documents he needs to sign, after which it can make queries of the form example.com/documents and example.com/document/15 it needs to only access their documents and error if trying to obtain/remove/modify someone else's document.

How to organize the log in user and verify ownership of the document to the user when removing/updating documents?
September 19th 19 at 13:28
4 answers
September 19th 19 at 13:30
Solution
usually such things are done using tokens. ie on the first request the client identificireba in the system and receives a unique token ( number\string\hash ) and all subsequent message sends this token and based on it defined its rights and opportunities.

if possible, I'd looked in the direction of spring-ws and spring-security. they are more or less successful attempt to provide for this convenient API. and almost out of the box. but I doubt the usefulness.
Thanks for the reply.

But as the client to send the token to the server would not want to write it in the URL, what do you think if the logged-in user to store @SessionScoped Bina, what could be the problem?

Considered JAAS for this purpose, but there can be controlled access only to the methods as a whole, and not make the restriction element by element in one method in spring-security similarly? - brandyn_Schuli commented on September 19th 19 at 13:33
: yeah, only a whole method, otherwise nothing.

if in detail I imagine it like this.

client ---> server
username + MD5 password

the client <--- server
token (randomly generadas string) + adds compliance with the user-token in mapou\session.

all subsequent connections are made using token, you do not want in the url, use post.

all validation logic can be put in the aspect that handles the execution of the method annotated, for example, the @Secured annotation.

For aspects, you can use AspectJ - toni66 commented on September 19th 19 at 13:36
well, if it's all to do very nice and good, without resorting to the use of third-party libraries, do not understand just what you need item-by-item limitation, because if the user makes a request example.com/document/15 and does not have access to the document 15 is to return an error, that's all there is to it - toni66 commented on September 19th 19 at 13:39
:
> because if the user makes a request example.com/document/15 and does not have access
> to the document 15 is to return an error, that's all

return error and not document, in my understanding, this is element by element access - access control list (thank you )
but the problem is that it checks your document and someone else will have to write in each update method remove the changes, this was the first idea of the solution, but do not want to copy-paste. - brandyn_Schuli commented on September 19th 19 at 13:42
: I'm telling you. look to the side aspect. if you explain the use of aspect in your case - you create a class SecurityControlAspect it describes the validation logic to access and put to him that he would have worked when using methods annotated with @Secured annotation. Hang this annotation to the desired methods and all. everything works. all is protected. Inside of the aspect, you will get your own slice method. i.e. before execution, perform the necessary inspections and in case of error, return an error. - toni66 commented on September 19th 19 at 13:45
: you can read more about aspects in the guides on AspectJ

Approximately would be something like this


public class SecurityControlAspect{
@Around("@annotation(com.test.security.Secure)") // specify the cut-off point
public Object traceMethod(ProceedingJoinPoint pjp) throws Throwable { //get slice method
if(checkAccess()){
Object o = pjp.proceed(); // "execute" method in case of successful verification
return o;
}else{
return error; //return error if no access
}
}
} - toni66 commented on September 19th 19 at 13:48
About Aspect understand, thank you

In JEE, this is called the interceptors @Interceptors - brandyn_Schuli commented on September 19th 19 at 13:51
: interceptor and aspects are different things, at the time I read about it. but the difference is so strange and obscure that to understand it is not possible. at least for me. - toni66 commented on September 19th 19 at 13:54
I understand this is a different solve one problem. Fundamentally they solve one problem, sort of. - brandyn_Schuli commented on September 19th 19 at 13:57
September 19th 19 at 13:32
Solution
Spring security access control lists for example
docs.spring.io/spring-security/site/docs/3.0.x/ref...
access control list is just what you need in JEE stack has an API for this, or just the spring ? - brandyn_Schuli commented on September 19th 19 at 13:35
Perhaps there is something non-standard for this. Standard analogue is missing. Overall, not too difficult to implement a similar approach. - toni66 commented on September 19th 19 at 13:38
Thanks for the help! - toni66 commented on September 19th 19 at 13:41
September 19th 19 at 13:34
For example you can create a field createdBy or owner, which will store the user who created the document. And when you try to access someone else's document to return a status 403.
To transmit data about the user you can either use the cookie in each request to transfer username/password.
Thanks for the report.
Document and User are of course related, each user knows its documents and each document knows its owner.

Assume on the server as I will then know what the user makes a request, but then in every method for working with the document will have to write code to verify the belonging of the document to the user, I would like to summarize and make this check in one place, so you don't have takes care of adding the working methods with the document. - brandyn_Schuli commented on September 19th 19 at 13:37
September 19th 19 at 13:36
The user login system is to make using ready framework. I'm using Apache Shiro. To write something of their own to authorize just not worth it.

The ownership verification document to the user can be done via the user ID (PK in the database, for example): when the document is created, the user ID recorded in the document, while edit/delete a document comparing the current user ID and the user ID stored in the document. When using Shiro to obtain the current user is not the problem.

Find more questions by tags RESTful APIJava EEJava