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

Authorization and Statelessness

Expand Messages
  • Shea Levy
    Hi all, Why doesn t authorization violate the statelessness constraint of REST? It seems to reduce visibility (monitoring systems need to know both the request
    Message 1 of 4 , Dec 10, 2012
    View Source
    • 0 Attachment
      Hi all,

      Why doesn't authorization violate the statelessness constraint of REST?
      It seems to reduce visibility (monitoring systems need to know both the
      request datum AND the user's access rights to understand a request) and
      scalability (server needs to store access-control metadata across
      requests). What makes this different from, say, personalizing a response
      based on the client's username?

      Cheers,
      Shea Levy
    • mike amundsen
      Shea: Why doesn t authorization violate the statelessness constraint of REST? It seems to reduce visibility (monitoring systems need to know both the
      Message 2 of 4 , Dec 10, 2012
      View Source
      • 0 Attachment
        Shea:

        <snip>
        Why doesn't authorization violate the statelessness constraint of REST?
        It seems to reduce visibility (monitoring systems need to know both the
        request datum AND the user's access rights to understand a request) 
        </snip>
        you can use the Authorization header to make the auth info visible

        server's don't need to "understand" access rights, just apply them. think about cases where the authentication is done by party A (oAuth), the authorization list is handled by party B (UMA), and the source material to access is handled by party C.

        <snip>
        and scalability (server needs to store access-control metadata across
        requests). 
        </snip>
        there is no requirement that servers MUST store AC data across requests. in fact, i don't to this in my work. maybe an auth proxy does it, however.

        </snip>
        What makes this different from, say, personalizing a response
        based on the client's username?
        </snip>





        On Mon, Dec 10, 2012 at 3:32 PM, Shea Levy <shea@...> wrote:
        Hi all,

        Why doesn't authorization violate the statelessness constraint of REST?
        It seems to reduce visibility (monitoring systems need to know both the
        request datum AND the user's access rights to understand a request) and
        scalability (server needs to store access-control metadata across
        requests). What makes this different from, say, personalizing a response
        based on the client's username?

        Cheers,
        Shea Levy


        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/rest-discuss/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/rest-discuss/join
            (Yahoo! ID required)

        <*> To change settings via email:
            rest-discuss-digest@yahoogroups.com
            rest-discuss-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            rest-discuss-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/


      • Eric J. Bowman
        ... There s nothing inherently unRESTful about personalization. Basing it on digest auth gives us caching advantages over both cookies, and tying it to
        Message 3 of 4 , Dec 10, 2012
        View Source
        • 0 Attachment
          Shea Levy wrote:
          >
          > What makes this different from, say, personalizing a response based
          > on the client's username?
          >

          There's nothing inherently unRESTful about personalization. Basing it
          on digest auth gives us caching advantages over both cookies, and tying
          it to /{username}/ URI allocation schemes. What we're after in REST is
          optimizing the hell out of GET, remember...

          Say I have a resource called "newsletter" I want all guests to be able
          to read, personalized for registered members using client-side XSLT to
          handle the mail-merge. The HTML representation of the newsletter must
          be the same for all users so we can set cache-control: public. It
          contains code which calls an XSLT transformation residing in an
          external .xsl file, whose URL must not vary for the sake of caching.

          But, that .xsl resource doesn't need to return the same representation
          for all users. The personal.xsl resource sets Vary: Authorization and
          has no 401 or 403 response. It has a 200 OK response which sets cache-
          control: public for unauthorized users, personalizing the newsletter for
          "Guest" (as opposed to, say, "Dave") which functions as a login link;
          whereas Dave would be linked to his control-panel UI. For example.

          Authenticated users GET a 303 redirection to the personal.xsl file in
          their user directory, which has cache-control: private set. Note that
          the personal.xsl files in this example apply to all newsletters, so
          it's useful to cache them. Note also that this is all invisible to the
          user, dereferencing the newsletter resource results in a personalized
          newsletter application steady-state -- which is a representation of the
          newsletter resource the user dereferenced.

          Actually, the HTML representation should be personalized for Guest by
          default, with the guest personal.xsl file containing an identity
          transform (does nothing). Also, the 303 redirects are cache-control:
          private.

          We can expand the example to only work this way for user-agents which
          Accept: application/xhtml+xml (which all do client-side XSLT 1 nowadays)
          while performing the XSLT transformation server-side and sending the
          personalized 200 OK response as text/html with cache-control: private
          for other user-agents (public, if not logged in). What this does is
          expand the set of representations such that each user now has two
          possible 200 OK responses, HTML and XHTML. Don't forget Vary: Accept.

          This isn't "the" RESTful way to do personalization, merely my attempt
          at a very simple example of basic mail-merge functionality in the REST
          idiom, to help answer your questions...

          >
          > Why doesn't authorization violate the statelessness constraint of
          > REST?
          >

          I'm going to turn that around on you, and ask what is it about my
          example you find stateful, specifically?

          >
          > It seems to reduce visibility (monitoring systems need to know
          > both the request datum AND the user's access rights to understand a
          > request)
          >

          Not really; intermediaries just need to know a user *has* access rights.
          As to visibility, if my example didn't have that property, it wouldn't
          have graceful degradation from highly-cacheable client-side merging
          down to cache-miss server-side merging.

          >
          > and scalability (server needs to store access-control metadata across
          > requests).
          >

          Sorry, not seeing it. The access-control metadata is part of the
          request, which leads to scalability. That a cookie is being used as
          access-control metadata is not apparent from such a request. It seems
          to me that the worst-case scenarios in my example, in terms of
          scalability vis-a-vis cache-hit ratio, are the best-case scenarios of
          non-RESTful approaches to personalization.

          IOW, that most requests cause processing on the server is what's
          expected with cookies, while REST gives me the means to avoid even
          contacting the server in many if not most cases, for the given example.
          The more millions of users, the greater the likelihood the newsletter's
          already cached closer to the user than the origin server, meaning
          server resource utilization per-user decreases as users increase, which
          is the real payoff to REST.

          -Eric
        • Mike Kelly
          Eric, Please could you start adding a tl;dr summary to the top of your posts Cheers, M ... -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly
          Message 4 of 4 , Dec 11, 2012
          View Source
          • 0 Attachment
            Eric,

            Please could you start adding a tl;dr summary to the top of your posts

            Cheers,
            M


            On Tue, Dec 11, 2012 at 7:24 AM, Eric J. Bowman <eric@...> wrote:
             

            Shea Levy wrote:
            >
            > What makes this different from, say, personalizing a response based
            > on the client's username?
            >

            There's nothing inherently unRESTful about personalization. Basing it
            on digest auth gives us caching advantages over both cookies, and tying
            it to /{username}/ URI allocation schemes. What we're after in REST is
            optimizing the hell out of GET, remember...

            Say I have a resource called "newsletter" I want all guests to be able
            to read, personalized for registered members using client-side XSLT to
            handle the mail-merge. The HTML representation of the newsletter must
            be the same for all users so we can set cache-control: public. It
            contains code which calls an XSLT transformation residing in an
            external .xsl file, whose URL must not vary for the sake of caching.

            But, that .xsl resource doesn't need to return the same representation
            for all users. The personal.xsl resource sets Vary: Authorization and
            has no 401 or 403 response. It has a 200 OK response which sets cache-
            control: public for unauthorized users, personalizing the newsletter for
            "Guest" (as opposed to, say, "Dave") which functions as a login link;
            whereas Dave would be linked to his control-panel UI. For example.

            Authenticated users GET a 303 redirection to the personal.xsl file in
            their user directory, which has cache-control: private set. Note that
            the personal.xsl files in this example apply to all newsletters, so
            it's useful to cache them. Note also that this is all invisible to the
            user, dereferencing the newsletter resource results in a personalized
            newsletter application steady-state -- which is a representation of the
            newsletter resource the user dereferenced.

            Actually, the HTML representation should be personalized for Guest by
            default, with the guest personal.xsl file containing an identity
            transform (does nothing). Also, the 303 redirects are cache-control:
            private.

            We can expand the example to only work this way for user-agents which
            Accept: application/xhtml+xml (which all do client-side XSLT 1 nowadays)
            while performing the XSLT transformation server-side and sending the
            personalized 200 OK response as text/html with cache-control: private
            for other user-agents (public, if not logged in). What this does is
            expand the set of representations such that each user now has two
            possible 200 OK responses, HTML and XHTML. Don't forget Vary: Accept.

            This isn't "the" RESTful way to do personalization, merely my attempt
            at a very simple example of basic mail-merge functionality in the REST
            idiom, to help answer your questions...


            >
            > Why doesn't authorization violate the statelessness constraint of
            > REST?
            >

            I'm going to turn that around on you, and ask what is it about my
            example you find stateful, specifically?


            >
            > It seems to reduce visibility (monitoring systems need to know
            > both the request datum AND the user's access rights to understand a
            > request)
            >

            Not really; intermediaries just need to know a user *has* access rights.
            As to visibility, if my example didn't have that property, it wouldn't
            have graceful degradation from highly-cacheable client-side merging
            down to cache-miss server-side merging.


            >
            > and scalability (server needs to store access-control metadata across
            > requests).
            >

            Sorry, not seeing it. The access-control metadata is part of the
            request, which leads to scalability. That a cookie is being used as
            access-control metadata is not apparent from such a request. It seems
            to me that the worst-case scenarios in my example, in terms of
            scalability vis-a-vis cache-hit ratio, are the best-case scenarios of
            non-RESTful approaches to personalization.

            IOW, that most requests cause processing on the server is what's
            expected with cookies, while REST gives me the means to avoid even
            contacting the server in many if not most cases, for the given example.
            The more millions of users, the greater the likelihood the newsletter's
            already cached closer to the user than the origin server, meaning
            server resource utilization per-user decreases as users increase, which
            is the real payoff to REST.

            -Eric




            --
            Mike

            http://twitter.com/mikekelly85
            http://github.com/mikekelly
            http://linkedin.com/in/mikekelly123
          Your message has been successfully submitted and would be delivered to recipients shortly.