Re: Semi-public resources in Uniform Messaging

On Thu, Dec 10, 2009 at 1:48 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 9 Dec 2009, Tyler Close wrote:
>>
>> If you're willing to tolerate a little bit of implementation mechanism,
>> I can do you one better on the UI side.
>
> Generally speaking, server-to-server communication is highly undesireable,
> as it requires far more work on all sides.
>
>
>> From the user's perspective, the UI will be:
>>
>>  - User visits site B and says nothing unique to site B.
>>  - Users sees his data from site A on site B.
>>
>> Meaning the user won't have to start a login session with site A before
>> using site B. They can just go to site B and immediately get full
>> functionality.
>>
>> For each user:
>> 1. Site B generates an unguessable token and associates it with a user account.
>> 2. A page from Site B does an HTML <form> post of the token to Site A.
>> 3. Server-side, Site A sends a request to Site B containing the token
>> and the corresponding unguessable user feed URL.
>> 4. Site B stores the feed URL in the user account.
>> 5. From then on, a page from Site B can do a direct GET on the feed
>> URL. Steps 1 through 4 are a one-time setup.
>>
>> All of the above is invisible to the user. There are no user actions
>> required. The implementation is fairly straightforward and the UI is
>> strictly superior to your ideal UI.
>
> How is the user recognised if he gives nothing unique to site B and
> doesn't login to site A?

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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 10 December 2009 17:59:37 UTC