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

Re: [rest-discuss] Security and REST

Expand Messages
  • S. Mike Dierken
    ... From: Mark Baker ... Since the Web has migrated on its own to a system where the server holds authentication information on the
    Message 1 of 23 , Nov 7, 2002
    View Source
    • 0 Attachment
      ----- Original Message -----
      From: "Mark Baker" <distobj@...>

      > The client ends up holding *less* state; state that it would
      > normally have, such as id/password, are held on the server and
      > the client is just given a "receipt" for them. The server is
      > holding state on the client's behalf. That's the problem.
      >
      Since the Web has migrated on its own to a system where the server holds
      authentication information on the client's behalf, doesn't this indicate an
      actual benefit to that approach?

      Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
      being unsecure, why do so many systems use something else?
      And why isn't there an RFC describing/standardizing current practice? The
      servlet engines I know have a servlet config for authentication called 'form
      auth' which makes it easy to use POST to authenticate & then pass down a
      cookie.

      Wouldn't it make sense to describe a use of HTML FORM that indicated to the
      user-agent (the browser) that it was 'authentication' information and then
      the browser could send it in the correct header? Or maybe a new HTML element
      like <AUTH> or something...
    • Paul Prescod
      ... Exactly! But perhaps we can use persistent connections, inclusions and prefetching to get more granular. Perhaps the page that is returned consists mostly
      Message 2 of 23 , Nov 7, 2002
      View Source
      • 0 Attachment
        S. Mike Dierken wrote:
        >...
        >>http://www.mynews.com/
        >>
        >>or like this:
        >>
        >>http://www.mynews.com?prefs=http://mypreferences.com/~prescod
        >
        >
        > Wouldn't it be hard to do caching that way? Or was the thought that
        > preferences (per representation changes based on personal choices) breaks
        > caching anyway?

        Exactly!

        But perhaps we can use persistent connections, inclusions and
        prefetching to get more granular. Perhaps the page that is returned
        consists mostly of "includes" and those includes are cached or not
        cached based on whether they are specific to you or not.

        >>No matter what device you were using, you would point the site at your
        >>consistent preferences-URI.
        >
        > The same URI for each device? This is what I would like, but in practice
        > that doesn't happen all that often.

        None of this happens in practice. It is a proposal. ;)

        >...
        >
        > Wasn't there several attempts at this 'shared preferences' approach? I can't
        > find any references right now...

        Netscape had a remote preferences feature but I'm not sure if it covered
        cookies. Hailstorm was to be more or less a remote cookie repository.
        But they couldn't find a business model for it because the natural home
        for it is at the ISP (or at least portal) and the biggest ISP in the
        world would NEVER cooperate with Microsoft. Plus, ISPs seem to have
        frozen the set of applications they are willing to deliver around 1995.
        How many of them are working to roll out Jabber or multicast or smart
        content caching techniques or decent spam filtering or universal inboxes
        (=phone and email) or ...

        They are about as imaginative as cable TV companies because these days
        they _are_ cable TV companies.

        Paul Prescod
      • Mark Baker
        ... That s certainly *an* approach, but it s stateful not stateless because the preferences form part of the meaning of the message, but are not in the
        Message 3 of 23 , Nov 7, 2002
        View Source
        • 0 Attachment
          On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote:
          > My thought is that if the Web-as-we-use it were architected entirely
          > according to REST, then "client-side" state (not username/passwords, but
          > preferences, etc.) would more likely live at any URI-addressable home.
          > So you might launch your favorite news site like this:
          >
          > http://www.mynews.com/
          >
          > or like this:
          >
          > http://www.mynews.com?prefs=http://mypreferences.com/~prescod

          That's certainly *an* approach, but it's stateful not stateless because
          the preferences form part of the meaning of the message, but are not in
          the message.

          MB
          --
          Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
          http://www.markbaker.ca http://www.idokorro.com
        • Mark Baker
          ... All I know about this, I heard from others. Mnot would be the best person to comment on the specifics. ... Sorry, I meant any *request* header. But it
          Message 4 of 23 , Nov 7, 2002
          View Source
          • 0 Attachment
            On Thu, Nov 07, 2002 at 02:38:30PM -0700, Lee Fife wrote:
            > So, the caches are built to only support negotiation on the Accept and
            > Accept-* headers? The set of headers the cache looks at is built in? And
            > presumably if the response Vary header specifies some other request header,
            > then the response isn't cached?

            All I know about this, I heard from others. Mnot would be the best
            person to comment on the specifics.

            > > Vary can name any header, even extension ones. Just like Connection.
            >
            > So, am I misreading the rfc: " Field-names listed in Vary headers are those
            > of request-headers.". (Sect 14.3) Instead, you're saying that Vary can name
            > any of the headers present in a request message? (sect 5)
            >
            > Request = Request-Line ; Section 5.1
            > *( general-header ; Section 4.5
            > | request-header ; Section 5.3
            > | entity-header ) ; Section 7.1
            > CRLF
            > [ message-body ] ; Section 7.2
            >
            > So, Vary can include anything from general-header + request-header +
            > entity-header?

            Sorry, I meant any *request* header. But it can be any extension
            header too, not just those in the HTTP spec, which is what I thought
            you were talking about.

            MB
            --
            Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
            http://www.markbaker.ca http://www.idokorro.com
          • Mark Baker
            ... For sure, there s lots of benefits to them; they re a catch-all, they re easy to use and implement, etc.. But there s also serious disadvantages, such as
            Message 5 of 23 , Nov 7, 2002
            View Source
            • 0 Attachment
              On Thu, Nov 07, 2002 at 09:25:12PM -0500, S. Mike Dierken wrote:
              > Since the Web has migrated on its own to a system where the server holds
              > authentication information on the client's behalf, doesn't this indicate an
              > actual benefit to that approach?

              For sure, there's lots of benefits to them; they're a catch-all, they're
              easy to use and implement, etc.. But there's also serious disadvantages,
              such as messing up browsing (i.e. hitting "Back" doesn't remove the
              cookie), plus resource consumption on the server. Obviously the pros
              outweight the cons for browsers.

              Cookies are the way they are because they got deployed first, and they
              did the job. That doesn't mean we can't do better for non-browser based
              apps, which was I was so disappointed to see the WS-I Basic Profile
              support them as a state mechanism.

              > Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
              > being unsecure, why do so many systems use something else?

              As you suggest below, I believe it's the lack of a UI.

              > And why isn't there an RFC describing/standardizing current practice? The
              > servlet engines I know have a servlet config for authentication called 'form
              > auth' which makes it easy to use POST to authenticate & then pass down a
              > cookie.

              Well, that doesn't impact the protocol, so I don't know what value
              there would be to doing that, other than illustrative.

              > Wouldn't it make sense to describe a use of HTML FORM that indicated to the
              > user-agent (the browser) that it was 'authentication' information and then
              > the browser could send it in the correct header? Or maybe a new HTML element
              > like <AUTH> or something...

              Yep.

              MB
              --
              Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
              http://www.markbaker.ca http://www.idokorro.com
            • Bill de hÓra
              ... The back button is a (literally) a world in itself and cookies are incidental to it. ... Maybe. But if we keep refusing to use TTPs then there isn t a
              Message 6 of 23 , Nov 8, 2002
              View Source
              • 0 Attachment
                Mark Baker wrote:

                > For sure, there's lots of benefits to them; they're a catch-all, they're
                > easy to use and implement, etc.. But there's also serious disadvantages,
                > such as messing up browsing (i.e. hitting "Back" doesn't remove the
                > cookie), plus resource consumption on the server. Obviously the pros
                > outweight the cons for browsers.

                The back button is a (literally) a world in itself and cookies are
                incidental to it.

                > Cookies are the way they are because they got deployed first, and they
                > did the job.

                Maybe. But if we keep refusing to use TTPs then there isn't a better
                game in town that storing state on servers. I'll also observe that
                even if cookies vanished tommorrow, the server would still need to
                hold state to deal with back button 'semantics', which are not
                unlike trying to write software while an evil pixie inserts random
                goto statements into the code.


                >That doesn't mean we can't do better for non-browser based
                > apps, which was I was so disappointed to see the WS-I Basic Profile
                > support them as a state mechanism.

                Absolutely.

                Bill de hÓra
              • Paul Prescod
                ... Yes, and this is a known deficiency with both HTML forms and XForms. Unfortunately the REST/HTTP community didn t push the issue with XForms. By the time I
                Message 7 of 23 , Nov 8, 2002
                View Source
                • 0 Attachment
                  S. Mike Dierken wrote:
                  >...
                  >
                  > Wouldn't it make sense to describe a use of HTML FORM that indicated to the
                  > user-agent (the browser) that it was 'authentication' information and then
                  > the browser could send it in the correct header? Or maybe a new HTML element
                  > like <AUTH> or something...

                  Yes, and this is a known deficiency with both HTML forms and XForms.

                  Unfortunately the REST/HTTP community didn't push the issue with XForms.
                  By the time I became very knowledgable about XForms, REST and the
                  interaction between them, the XForms working group was already exhausted
                  and in somewhat of a defensive mode. Now they are almost at CR stage and
                  will resist changes even more strongly.

                  Perhaps XHTML 2.0 is the next opportunity to attack the problem. Another
                  option is to just write a W3C NOTE ... or if anyone is ambitious enough
                  (and works at a member company) to try to push the NOTE through the
                  process as its own WD. "HTTP Authentication extensions for XForms and
                  XHTML".

                  When I mentioned the problem to Dan Connolly at a conference he slapped
                  his head and said something like: "We STILL haven't fixed that? Damn."
                  It's a little thing but with a wide impact on how people build websites...

                  Paul Prescod
                • Lee Fife
                  Sorry to beat a dead horse here, but I m trying to understand what the HTTP rfc actually means. ... Finally: * yes, I was talking about extension headers.
                  Message 8 of 23 , Nov 8, 2002
                  View Source
                  • 0 Attachment
                    Sorry to beat a dead horse here, but I'm trying to understand what the HTTP
                    rfc actually means.

                    Anyway, Mark said:
                    > Vary can name any header, even extension ones. Just like Connection.

                    I replied, quoting from rfc 2068:
                    > So, am I misreading the rfc: "Field-names listed in Vary headers are those
                    > of request-headers.". (Sect 14.3)

                    And Mark responded:
                    > Sorry, I meant any *request* header. But it can be any extension
                    > header too, not just those in the HTTP spec, which is what I thought
                    > you were talking about.

                    Finally:
                    * yes, I was talking about extension headers. Those seem like a natural
                    place to put authentication credentials if you're using some non-standard
                    scheme
                    * I was interpreting "request-headers" as referring specifically to the set
                    of headers defined in the production for request-header in Sect 5.3. It
                    seems like Mark is saying "request-headers" should mean any header in the
                    request message? BTW, I'd like this better, cause then you could Vary on
                    extension headers. But, then I'd expect the rfc to say something like "any
                    request header".

                    But, practically, what's the impact of this? Is an intermediary justified in
                    rejecting a response message if it has illegal headers in it? E.g., could a
                    firewall fail to pass thru a response containing a "Vary: foobar" header
                    (where foobar is some extension header from the request)? Or could a cache
                    ignore the unrecognized Vary header fields and return the wrong page to a
                    subsequent request? (Of course, a broken firewall or cache could do anything
                    ... I'm talking about "correct per the rfc" behavior.)

                    -Lee
                  • Lee Fife
                    ... My two cents: In the systems I ve built, lack of UI is exactly the reason we re rejected HTTP Auth. Two main problems: * usability: simple as it seems, the
                    Message 9 of 23 , Nov 8, 2002
                    View Source
                    • 0 Attachment
                      >> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
                      >> being unsecure, why do so many systems use something else?

                      >As you suggest below, I believe it's the lack of a UI.

                      My two cents: In the systems I've built, lack of UI is exactly the reason
                      we're rejected HTTP Auth. Two main problems:
                      * usability: simple as it seems, the uname/pw dialog that the browsers
                      present seems to stump naive users. There's no feedback if you enter bad
                      credentials (besides the dialog popping up again), there's no help, there's
                      no way to retrieve a forgotten password.
                      * branding/look&feel: no way to control the UI. So you can't make it look
                      like the rest of your app.

                      Insecurity of the Basic scheme hasn't been a big deal for a these apps:
                      newsletters, targetted prof databases, etc.

                      Given configurable client-side control of the auth UI, I think we would have
                      happily used HTTP auth for almost all these apps.

                      -Lee
                    • Paul Prescod
                      ... So you would say that all your preferences should be sent in every message? We re talking about HTTP GET, so it would have to be HTTP headers...which is a
                      Message 10 of 23 , Nov 8, 2002
                      View Source
                      • 0 Attachment
                        Mark Baker wrote:
                        > On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote:
                        >
                        >>My thought is that if the Web-as-we-use it were architected entirely
                        >>according to REST, then "client-side" state (not username/passwords, but
                        >>preferences, etc.) would more likely live at any URI-addressable home.
                        >>So you might launch your favorite news site like this:
                        >>
                        >>http://www.mynews.com/
                        >>
                        >>or like this:
                        >>
                        >>http://www.mynews.com?prefs=http://mypreferences.com/~prescod
                        >
                        >
                        > That's certainly *an* approach, but it's stateful not stateless because
                        > the preferences form part of the meaning of the message, but are not in
                        > the message.

                        So you would say that all your preferences should be sent in every
                        message? We're talking about HTTP GET, so it would have to be HTTP
                        headers...which is a pain for structured information.

                        What if each individual page on a site uses only some small subset of
                        them? There are performance costs to sending them all every time. It is
                        quite a bit cheaper to send a URL or list of URLs and let the recipient
                        choose which to dereference and how deeply to follow links into the
                        representations it finds.

                        ====

                        To me, statelessness has these advantages:

                        1. Conversations can migrate between agents and devices because there
                        is no privileged information associated with the connection between the
                        initial "initator" and the "listener". My proposal preserves this.

                        2. Filtering, caching and other intermediary projects are easier
                        because there is no need to store state between messages. My proposal
                        preserves this. Filters and caches _may_ need to dereference URIs, but
                        they don't have to maintain state themselves. That is important for
                        scalability. It means cache's memory usage does not increase with the
                        number of conversations they watch.

                        3. If a message is missed or a conversation partner dies, it is easy
                        to "reboot" and "resynch" the client and server state through transfer
                        of representations. My proposal preserves this.

                        4. Logs are explicit so that historically you can look at a single
                        message in isolation and understand its meaning entirely. My proposal
                        does not preserve this.

                        In a perfect world, I would get all 4 every time. But if the only
                        problem is really "4." then I consider that an acceptable cost. On the
                        other hand, if there is some other major benefit of scalability I am
                        missing...

                        Paul Prescod
                      • Andrew Tipton
                        ... My biggest concern with HTTP Auth (as currently implemented by browsers) is that once you ve logged in, there is no way for the user to tell the browser to
                        Message 11 of 23 , Nov 8, 2002
                        View Source
                        • 0 Attachment
                          > >> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic'
                          > >> auth-type being unsecure, why do so many systems use something else?
                          > >
                          > >As you suggest below, I believe it's the lack of a UI.
                          >
                          > My two cents: In the systems I've built, lack of UI is exactly the reason
                          > we're rejected HTTP Auth. Two main problems:
                          > * usability: simple as it seems, the uname/pw dialog that the browsers
                          > present seems to stump naive users. There's no feedback if you enter bad
                          > credentials (besides the dialog popping up again), there's no help, there's
                          > no way to retrieve a forgotten password.
                          > * branding/look&feel: no way to control the UI. So you can't make it look
                          > like the rest of your app.
                          My biggest concern with HTTP Auth (as currently implemented by browsers) is
                          that once you've logged in, there is no way for the user to tell the browser
                          to "forget" that username and password! You have to close ALL browser
                          windows to get it to forget the authentication.

                          Wouldn't it be nice if the web browser had a statusbar icon (similar to the
                          lock for HTTPS) indicating that it was currently sending authentication
                          information with each request? Clicking on this icon would allow the user to
                          "manage" their current logins, including an easy way to logout from a given
                          site (where logout simply means no longer sending authentication
                          information).

                          Fixing this problem would make HTTP auth usable by browsers. Of course, UI
                          improvements would be welcome.........
                          > Given configurable client-side control of the auth UI, I think we would
                          > have happily used HTTP auth for almost all these apps.
                          Agreed! The server should be able to return a simple HTML document as the
                          entity-body of the HTTP 401 Unauthorized response. Just need a standard way
                          to inform the browser which field is the username, and which is the password.

                          -Andrew
                        • Mark Baker
                          ... Hmm, interesting, I never noticed that. Not sure what the general implications of it are, or if it s a bug, but at least there s this bit from 12.1 to
                          Message 12 of 23 , Nov 8, 2002
                          View Source
                          • 0 Attachment
                            On Fri, Nov 08, 2002 at 12:02:59PM -0700, Lee Fife wrote:
                            > * I was interpreting "request-headers" as referring specifically to the set
                            > of headers defined in the production for request-header in Sect 5.3. It
                            > seems like Mark is saying "request-headers" should mean any header in the
                            > request message? BTW, I'd like this better, cause then you could Vary on
                            > extension headers. But, then I'd expect the rfc to say something like "any
                            > request header".

                            Hmm, interesting, I never noticed that. Not sure what the general
                            implications of it are, or if it's a bug, but at least there's this
                            bit from 12.1 to cover your Vary question;

                            "However, an
                            origin server is not limited to these dimensions and MAY vary the
                            response based on any aspect of the request, including information
                            outside the request-header fields or within extension header fields
                            not defined by this specification."

                            > But, practically, what's the impact of this? Is an intermediary justified in
                            > rejecting a response message if it has illegal headers in it? E.g., could a
                            > firewall fail to pass thru a response containing a "Vary: foobar" header
                            > (where foobar is some extension header from the request)? Or could a cache
                            > ignore the unrecognized Vary header fields and return the wrong page to a
                            > subsequent request? (Of course, a broken firewall or cache could do anything
                            > ... I'm talking about "correct per the rfc" behavior.)

                            HTTP's processing model is a bit loose, but basically most software out
                            there is "liberal in what it receives" meaning that they won't likely
                            reject a message for containing a header which it doesn't recognize.

                            MB
                            --
                            Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

                            Will distribute objects for food
                          • S. Mike Dierken
                            ... From: Andrew Tipton ... is ... browser ... Same thing with cookies. Typical cookie based (distributed) apps send a response that
                            Message 13 of 23 , Nov 9, 2002
                            View Source
                            • 0 Attachment
                              ----- Original Message -----
                              From: "Andrew Tipton" <atipton@...>

                              > My biggest concern with HTTP Auth (as currently implemented by browsers)
                              is
                              > that once you've logged in, there is no way for the user to tell the
                              browser
                              > to "forget" that username and password! You have to close ALL browser
                              > windows to get it to forget the authentication.
                              Same thing with cookies.
                              Typical cookie based (distributed) apps send a response that has a cookie
                              with negative duration or something that signals the browser to delete the
                              cookie. There should be a corresponding capability in the HTTP Auth
                              approach.

                              >
                              > Wouldn't it be nice if the web browser had a statusbar icon (similar to
                              the
                              > lock for HTTPS) indicating that it was currently sending authentication
                              > information with each request? Clicking on this icon would allow the user
                              to
                              > "manage" their current logins, including an easy way to logout from a
                              given
                              > site (where logout simply means no longer sending authentication
                              > information).
                              Giving the users control over highly technical issues usually doesn't work.
                              Let the web app author present to the user the most appropriate form for
                              'log out'.

                              Okay... sounds like everybody wants this.
                              Who knows how to write a W3C NOTE?
                            • Mark Baker
                              ... As long as it s part of the *message*. Headers seem the obvious place, but the body s fine too. There s many ways to do this. ... Yep, very true. The
                              Message 14 of 23 , Nov 10, 2002
                              View Source
                              • 0 Attachment
                                On Fri, Nov 08, 2002 at 11:31:01AM -0800, Paul Prescod wrote:
                                > So you would say that all your preferences should be sent in every
                                > message? We're talking about HTTP GET, so it would have to be HTTP
                                > headers...which is a pain for structured information.

                                As long as it's part of the *message*. Headers seem the obvious place,
                                but the body's fine too. There's many ways to do this.

                                > What if each individual page on a site uses only some small subset of
                                > them? There are performance costs to sending them all every time. It is
                                > quite a bit cheaper to send a URL or list of URLs and let the recipient
                                > choose which to dereference and how deeply to follow links into the
                                > representations it finds.

                                Yep, very true. The WAPforum went back and forth on this for quite a
                                while with CC/PP. Initially, everybody assumed that the preferences
                                would be cached, but I'm pretty sure the final decision was to send
                                all the data in each message. I could be wrong, the final decision
                                happened after I left, and after I cared.

                                > To me, statelessness has these advantages:
                                >
                                > 1. Conversations can migrate between agents and devices because there
                                > is no privileged information associated with the connection between the
                                > initial "initator" and the "listener". My proposal preserves this.

                                Yep.

                                > 2. Filtering, caching and other intermediary projects are easier
                                > because there is no need to store state between messages. My proposal
                                > preserves this. Filters and caches _may_ need to dereference URIs, but
                                > they don't have to maintain state themselves. That is important for
                                > scalability. It means cache's memory usage does not increase with the
                                > number of conversations they watch.

                                Yep.

                                > 3. If a message is missed or a conversation partner dies, it is easy
                                > to "reboot" and "resynch" the client and server state through transfer
                                > of representations. My proposal preserves this.

                                State of preferences? Ok.

                                > 4. Logs are explicit so that historically you can look at a single
                                > message in isolation and understand its meaning entirely. My proposal
                                > does not preserve this.

                                Right.

                                > In a perfect world, I would get all 4 every time. But if the only
                                > problem is really "4." then I consider that an acceptable cost. On the
                                > other hand, if there is some other major benefit of scalability I am
                                > missing...

                                No, that's a good summary. With any design choice, it's pros vs. cons.

                                On the other hand, a simple policy decision could turn the same message
                                syntax into a stateless transaction, if the URI were to identify a
                                fixed preferences profile that didn't change over time. So if the
                                preferences change, the URI changes. This would allow you to include
                                URIs for fixed and common preference profiles, while including the
                                frequently-changing preferences by-value.

                                MB
                                --
                                Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

                                Will distribute objects for food
                              Your message has been successfully submitted and would be delivered to recipients shortly.