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

Re: [rest-discuss] Identifying user without sessions

Expand Messages
  • Jan Algermissen
    ... HTTP has built in authentication. See for example: http://www.ietf.org/id/draft-ietf-httpbis-p7-auth-16.txt
    Message 1 of 5 , Sep 8 12:58 PM
    • 0 Attachment
      On Sep 8, 2011, at 4: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...
      >

      HTTP has built in authentication.

      See for example:

      http://www.ietf.org/id/draft-ietf-httpbis-p7-auth-16.txt

      http://stackoverflow.com/questions/tagged/restful-authentication


      Jan

      > Many thanks
      >
      > jim
      >
      >
    • 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 2 of 5 , Sep 9 2:05 AM
      • 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 3 of 5 , Sep 12 10:30 PM
        • 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 4 of 5 , Sep 12 10:49 PM
          • 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.