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

Re: [rest-discuss] Security and REST

Expand Messages
  • 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 1 of 23 , Nov 7, 2002
      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 2 of 23 , Nov 7, 2002
        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 3 of 23 , Nov 7, 2002
          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 4 of 23 , Nov 7, 2002
            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 5 of 23 , Nov 8, 2002
              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 6 of 23 , Nov 8, 2002
                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 7 of 23 , Nov 8, 2002
                  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 8 of 23 , Nov 8, 2002
                    >> 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 9 of 23 , Nov 8, 2002
                      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 10 of 23 , Nov 8, 2002
                        > >> 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 11 of 23 , Nov 8, 2002
                          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 12 of 23 , Nov 9, 2002
                            ----- 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 13 of 23 , Nov 10, 2002
                              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.