Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Identifying user without sessions

Expand Messages
  • Marek Potociar
    You need to consider some form of stateless authentication. Here are few options to consider: - HTTP basic authentication is simplest but requires user to
    Message 1 of 5 , Sep 9, 2011
    • 0 Attachment
      You need to consider some form of stateless authentication.

      Here are few options to consider:

      - HTTP basic authentication is simplest but requires user to directly send credentials unencrypted. This is typically
      mitigated by switching to SSL and use HTTPS instead of plain HTTP, which is however still vulnerable to man in the
      middle attacks. Server is not required to store client credentials in plain text, which means client credentials are
      safe even in case of accidental server data leaks.

      - HTTP digest authentication is much more robust and safe even over plain HTTP, but requires implementing more complex
      algorithms. It also doubles the number of requests - each client request needs to be sent twice (see the protocol for
      explanation why). Again, server is not required to store client credentials in plain text, which means client
      credentials are safe even in case of accidental server data leaks.

      - WSSE is somewhere in between the basic and digest. It can be used over plain HTTP, it does not require 2 HTTP requests
      for every client request, but it does require server to store user credentials in a plain text (unlike the two protocols
      above) which makes the client credentials potentially vulnerable in case of a successful attack on the server.

      - you may also want to look at OAuth, which is becoming quite popular and can be used for implementing more advanced
      authentication and authorization scenarios.

      HTH,
      Marek

      On 09/08/2011 04:34 PM, jim.margetts wrote:
      >
      >
      > Hi,
      >
      > I'm new to REST and have a quick query:
      >
      > Most of the literature i've read about RESTful design warns against using any sort of sessions. I've always used
      > sessions to keep a track of whether is user is logged in to an application. What's the best way of achieving this
      > without using a session...
      >
      > Many thanks
      >
      > jim
      >
      >
    • bryan_w_taylor
      So generally how do you get rid of session state? Two choices: carry it with the message or turn it into resource state. Our solution was a mix of both. In
      Message 2 of 5 , Sep 12, 2011
      • 0 Attachment
        So generally how do you get rid of session state? Two choices: carry it with the message or turn it into resource state. Our solution was a mix of both.

        In OpenStack we have an authN component called keystone. When you log in, keystone gives you a token, a list of links, and from there you are expected to put this token as a header in your requests (assisted via code-on-demand). When the request arrives at a server with the token, we call a keystone resource to validate the token. This resource can be cached on either side of the SSL tunnel.

        --- In rest-discuss@yahoogroups.com, "jim.margetts" <jim.margetts@...> wrote:
        > Most of the literature i've read about RESTful design warns against using any sort of
        > sessions. I've always used sessions to keep a track of whether is user is logged in to an
        > application. What's the best way of achieving this without using a session...
      • Alexander Johannesen
        On Tue, Sep 13, 2011 at 3:30 PM, bryan_w_taylor ... +1 to this. In a few implementations I ve done this has also been done through an extra parameter (as
        Message 3 of 5 , Sep 12, 2011
        • 0 Attachment
          On Tue, Sep 13, 2011 at 3:30 PM, bryan_w_taylor
          <bryan_w_taylor@...> wrote:
          > In OpenStack we have an authN component called keystone. When you log in, keystone
          > gives you a token, a list of links, and from there you are expected to put this token as a
          > header in your requests (assisted via code-on-demand). When the request arrives at
          > a server with the token, we call a keystone resource to validate the token. This resource
          > can be cached on either side of the SSL tunnel.

          +1 to this. In a few implementations I've done this has also been done
          through an extra parameter (as opposed to header) as
          security_token=[hashed_token] for simpler implementations, but I do
          prefer forwarding the token in forms that RESTful clients pick up and
          passes forward (just look out for clients losing their tokens, forcing
          an extra authentication). I usually have a service (called
          ServiceStation for giggles) that handles validation and granting of
          security tokens across the network.


          Regards,

          Alex
          --
           Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
          --- http://shelter.nu/blog/ ----------------------------------------------
          ------------------ http://www.google.com/profiles/alexander.johannesen ---
        Your message has been successfully submitted and would be delivered to recipients shortly.