This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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)).
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.
Joined: Aug 19, 2005
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):
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).
Joined: Jun 18, 2003
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...
Joined: Aug 19, 2005
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".