0

I have read very nice answers here how to secure REST-services, but all of them are just pure theory and didn't help so much. How you implement JDBCRealm-FORM authentication when using REST?

Login form

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Login Form</title>
</head>

<body>
<form method="post" action="j_security_check">
<p>You need to log in to access protected information.</p>
<table>
   <tr>
      <td>User name:</td>
      <td><input type="text" name="j_username" /></td>
   </tr>
   <tr>
      <td>Password:</td>
      <td><input type="password" name="j_password" /></td>
   </tr>
</table>
<p><input type="submit" value="Login" /></p>
</form>
</body>
</html>

web.xml

<security-constraint>
    <web-resource-collection>
        <web-resource-name>How to protect REST</web-resource-name>
        <url-pattern>/protected/*</url-pattern>----> What is that in case of rest?
        <http-method>GET</http-method>
        <http-method>POST</http-method>
        <http-method>HEAD</http-method>
        <http-method>PUT</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>TRACE</http-method>
        <http-method>DELETE</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>admin</role-name>
        <role-name>customer</role-name>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>jdbcRealm</realm-name>

</login-config>
<security-role>
    <role-name>admin</role-name>
</security-role>
<security-role>
    <role-name>user</role-name>
</security-role>
<security-role>
    <description/>
    <role-name>customer</role-name>
</security-role>

QUESTIONS:

1) I have created JDBCRealm in Glassfish and it is working. I tested it with another jsf-app. In case of clien-REST-service what is for instance that: <url-pattern>/protected/*</url-pattern> In normal case it refers to "folder" where protected jsp/jsf/xhtml etc pages are, but where now?

2) What about session? I think that it is impossible to use session in stateless context

3) Is it even possible to use FORM-based authentication with REST?

4) Any links to tutorial where somebody wiser than me explain how to secure client - server rest application.

Sami
  • 2,179
  • 11
  • 43
  • 77

2 Answers2

1

You cannot have FORM auth with REST because every request must be complete in itself and stateless. Form with redirect isn't. You need to use a standard HTTP header-based mech like Basic, Digest, etc.

Michael-O
  • 17,130
  • 6
  • 51
  • 108
  • Is it so? I change auth to BASIC to test and get it working once in REST-project's JSP-page BUT not in html5-client what is using REST-services. Is it so that there is no timeout, nothing? So I can test it once and after that I have to restart my server to test it again? How about digest? Is this really that difficult or am I just stupid :) – Sami Apr 09 '13 at 19:50
  • Basic is not working in case of HTML5-client. Failed to load resource: the server responded with a status of 401 (Unauthorized) (22:52:28:196 | error, network) at http://localhost:8080/testService/userService. In HTML-client, it doesn't (of course) open the browser's username-password-window. – Sami Apr 09 '13 at 19:57
  • The servlet spec does only allow one `Authenticator` at the same time. But a browser should work fine with Basic. Everything else is configured incorrectly. – Michael-O Apr 10 '13 at 07:27
  • How is it possible to handle timeout and logout with BASIC and can you use html-form instead of browser login-window? It was strange that when I logged in with BASIC, I was always authorised and didn't realise how to log out etc. – Sami Apr 10 '13 at 10:21
  • Timeout requires a session. HTTP is stateless. A REST client cannot know that. Every request must be reauthenticated anyway. – Michael-O Apr 10 '13 at 10:41
  • How can I do it with BASIC authorisation? How can I authorise every request? How to kill the authorisation in server side? Thanks a lot for answering? I really need help with this, I wonder why this so empty space in web. Lot of text, less solutions and examples and tutorials. – Sami Apr 10 '13 at 10:50
1

1) I have created JDBCRealm in Glassfish and it is working. I tested it with another jsf-app. In case of clien-REST-service what is for instance that: /protected/* In normal case it refers to "folder" where protected jsp/jsf/xhtml etc pages are, but where now?

You can choose to protect the entire REST services subdomain, or a portion of it. Assuming you configured the root to be /rest, that is what you would put in your url-pattern.

2) What about session? I think that it is impossible to use session in stateless context

Depends on your REST implementation. With JAX-RS (Jersey) the answer is absolutely yes, you can use the HTTP session. You inject it into your resource class via a @Context annotation:

@Path("/echo")
public class EchoServiceImpl {
    @Context
    private HttpSession session;
}

Having confirmed that you can use the session, I would strongly advise against it, because RESTful calls are supposed to be stateless.

3) Is it even possible to use FORM-based authentication with REST?

It doesn't make sense using form based authentication for REST, no. You are designing services to be consumed by other computer systems, not by humans. There should be no interactive UI's involved in the process.

4) Any links to tutorial where somebody wiser than me explain how to secure client - server rest application.

This is a tough one, theres lots of guides out there but a lot of them are very specific to the particular technology stack being used in the REST implementation. As a start I would recommend you change your current configuration from FORM to BASIC, and also think about securing your endpoint with SSL. Do remember that when you use Basic Authentication, that you need to include the user credentials in an Authorization header:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

You can read up on how to compute the header here

Once comfortable with Basic/Digest authentication, you will then be ready to start looking at more advanced security options like OAuth.

Perception
  • 75,573
  • 19
  • 170
  • 185