File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes RESTful and security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "RESTful and security" Watch "RESTful and security" New topic
Author

RESTful and security

Teimatini Marin
Greenhorn

Joined: Jun 18, 2003
Posts: 5
I know, RESTful WebServices are stateles.

What about security... in the case I have 2 user: pedro and juan. And the following resource: http://miserver.com.mx/myresurces/{user}/personalInfo

Obviously pedro is not allowed to view juan's personal information... If I don't have state in the server side (session) how can I verify that juan is trying to access the URI http://miserver.com.mx/myresurces/juan/personalInfo and is not pedro...

I mean, the user could change the URI at browser side an access information he is not allow to view.

What am I lossing? Any suggestions-idea?


Thanks,

TMM
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42906
    
  69
You could use HTTP Basic Authentication to pass username and password in the HTTP headers.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Teimatini Marin wrote:I know, RESTful WebServices are stateless.

Not exactly. A resource has a state (REsource State Transfer). And the client can manage state. The statement that RESTful web services are stateless actually means that "application state" stays on the client.

So it is perfectly permissible for the client to acquire a "security token" after authentication. That security token is then submitted in an HTTP header with every request. A secured resource can then inspect the token (or delegate that job to a security subsystem) to determine whether the token entitles the user to perform the requested (GET,POST,PUT,DELETE,HEAD) operation. Of course this approach would still require that you secure your transport with SSL/TLS to prevent the token from being copied. Alternately you could use Atom's WSSE Authentication to determine whether the user knows his password (Atom API client example with WSSE authentication (Java)).

See also Securing the Atom Publishing Protocol

RESTful HTTP web services vs. Big Web Services (SOAP/WSDL)
Teimatini Marin
Greenhorn

Joined: Jun 18, 2003
Posts: 5
"security token"?? Could be a SessionID... right?

A secured resource can then inspect the token (or delegate that job to a security subsystem) to determine whether the token entitles the user to perform the requested (GET,POST,PUT,DELETE,HEAD) operation.
mmm... in the simplest case, Could this be a simple Filter Servlet that checks for a SessionID, verfies access and allows or denies access. Did I understood well?

Thanks for your ports.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Teimatini Marin wrote:"security token"?? Could be a SessionID... right?

No - the session ID is correlation identifier that is identifies session data that stores application state on the server side.

Neither the user's authentication or even authorization information is session data. This is why the Atom WSSE authentication protocol simply passes on the user id and password hash. However once the user is authenticated something still needs to decide what the user is authorized to do. In the simplest case the resource proceeds if WSSE authentication passes. In a more general case the resource would pass the WSSE token information, the HTTP command, and URI to a security sub system to authenticate the user and then authorize the action the resource is about to take. The security subsystem could then deny the request and the resource could return 401.

Now granted that functionality could actually be done by a filter because all the necessary information is readily available (without looking into the request body):
  • Request Method
  • Request URI
  • X-WSSE header

  • Now the filter can query the security subsystem which can instruct the filter to block access to the resource entirely, with status codes of 401 "Unauthorized", 403 "Forbidden" (e.g. not allowed access during this time of day) or 404 "Not Found" (i.e. pretend the resource doesn't even exist).
    Teimatini Marin
    Greenhorn

    Joined: Jun 18, 2003
    Posts: 5
    If your client runs over a web browser you don't need to do anything, the browser stores the sessionId for you. Then you can get the sessionId in a FilterServelt (for instance) an do there whatever you need...
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    There is more than "one type of state".

    In a true REST architecture application state is supposed to reside on the client to maximize scalability.
    That is where the tag line "Hypermedia as the Engine of Application State" comes from.

    The whole "session_id" concept is about application state that is stored on the server which diminishes scalability. A RESTful web application does not want to store application session information on the server. In a "regular" session-aware web application the session_id is often used for security purposes because the session is linked to the user, which leads to the security information related to that user. That security information is part of the "user state", not the session. A RESTful web application doesn't keep session data so for security information it will have to go directly to the "user state".
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: RESTful and security