Re: Semi-public resources in Uniform Messaging

On Thu, 10 Dec 2009, Tyler Close wrote:
> 
> OK, here's a fuller description of the exchange, that also meets the new 
> requirement of no server-to-server communication:
> 
> Initial assumptions:
> - Site A wants to give Site B access to all user feeds.
> - Site A and Site B do *not* share a username namespace, such as
> OpenID, so Site A is unable to just give Site B a table mapping
> usernames to unguessable URLs for feeds.
> - No server-to-server communication is allowed.
> - No user actions are allowed.
> 
> There are two phases to the solution.
> Grant: Site A grants Site B permission to access a particular user
> feed. This is a one-time setup operation per user account. In this
> phase, it is assumed that the user is either logged into Site A, or
> will log into the site on the first navigation request to the site.
> Exercise: Site B reads the feed. This happens every time the feed is
> accessed. In this phase, the user may or may not be logged into Site
> A, it doesn't matter. The user is logged into Site B.
> 
> So, whereas your CORS based solution requires a login to Site A for
> both phases, the UMP solution only requires a one-time login to Site A
> for the Grant Phase.
> 
> Grant Phase:
> 1. User logs into Site B.
> 
> 2. Site B generates an unguessable token (to be used for CSRF
> protection on a subsequent request) and associates it with the user
> account.
> 
> 3. A page from Site B does an HTML <form> post of the token to Site A,
> using a URL like <https://A/getfeed?csrf=asdf>. The "csrf" query
> string parameter holds the unguessable token generated in step 2.
> 
> 4. Site A receives a POST request containing the user's login cookies
> and the csrf token. Site A generates (or looks up) an unguessable URL
> for the user's feed. Site A responds with a 303 back to Site B that
> contains the feed URL and the csrf token, such as
> <https://B/gotfeed?csrf=asdf&feed=xxx>. The "feed" query string
> parameter holds the unguessable URL for the user's feed.
> 
> 5. Site B receives a GET request containing the user's login cookies,
> the csrf token and the feed URL. Site B does a lookup for the expected
> csrf token in the user's account. If the csrf token is not the
> expected one, Site B stops processing the request. Site B discards the
> csrf token. Site B stores the feed URL in the user's account. Site B
> responds with the normal, post-login user home page.
> 
> Excercise Phase:
> 1. A page from Site B gets the user feed URL from the user's account
> and uses a UniformRequest (XHR-like protocol for uniform requests) to
> do a GET request.
> 
> 2. Site A receives a GET request on a feed URL, looks up the
> corresponding feed data and returns it, along with the same-origin
> opt-out header.
> 
> 
> You can think of the funny little dance that the Grant Phase does as a
> way for Site A and Site B to conspire to force the user to do the
> copy-paste operation on the feed URL. Personally, I'd want Site B to
> support showing feeds from an unbounded set of sites, and would be
> content to do the copy-paste. For Ian's scenario, I've shown that you
> don't have to do it that way. The UI is strictly better than the one
> Ian had envisioned, since repeated login to Site A is no longer
> required. The algorithm also meets all the arbitrary constraints
> placed on its operation.

That looks _really_ complicated.

Here's an alternate proposal:

   Site A and site B agree that they're going to allow site B to read 
   rsources on site B. No secrets are exchanged.

   User logs into site A by loading a page on site A that offers a form 
   with two fields, username and password, which, when posted with the 
   correct values, sets a cookie on the user's UA.

   User visits site B. A static page does a GET using XHR to site B. The 
   GET is to a well-known URL, the same for all users. The UA includes in 
   the request an unforgable token identifying site B as the Origin, and 
   the cookies for site A to identify the user. Site A returns the data
   only if the cookies identify an active user session and the Origin 
   identifies a server that A has an agreement with.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 10 December 2009 18:18:13 UTC