[Wg-uma] Further protocol flow development

Paul C. Bryan email at pbryan.net
Thu Oct 29 01:45:18 EDT 2009


For discussion in tomorrow's meeting, some further work in the
end-to-end protocol flow.

Continuing the protocol design with LRDD/XRD in place, it occurred to me
that we can use this to allow OAuth profiles to be used for issuing
tokens between host and requester (H->R) and AM and requester (A->R),
making UMA an application of various OAuth profiles. I think this may
create further alignment with Christian's work.

The downside is again: more complexity. There's a higher number of XRDs
now, which means more indirection. The upside: much stronger alignment
with OAuth, and we get out of the authentication business, and get to
focus on authorization.

You'll note that I've pointed-out a MITM vector in step 3. Basically,
step 3 is half-baked at the moment. I sense the way out of this problem
is to have the host allocate an authorization resource in AM on behalf
of the requester and pass this to requester for required claims
negotiation. I was tempted to change it tonight, but feel like sleeping
on it would be a good idea.

Thanks Eve for providing some edits and an introductory section.


________________________________________________________________________

0. Introduction

In this example, the following access tokens are involved:

  H->A access token representing the host's authentication to the AM
(section 1.2)

  R->H access token representing the requester's authentication to the
host (section 2)

The following XRD descriptors are involved:

  Host root resource descriptor, provided by the AM to help hosts begin
the process of registration (section 1.1)

  H->A authentication descriptor, provided by the AM to help hosts
obtain an H->A access token (section 1.2)

  Host resource descriptor, provided by the AM to a specific host to
explain the unique interface it should use at the AM (section 1.4)

  R->H authentication descriptor, provided by the host to help
requesters obtain an R->H access token (section 2)

  Protected resource descriptor, provided by the host to help requesters
learn where to obtain access authorization (section 3)

XRD Type values stand for the following:

  http://wg-uma.net/core/1.0/... represents UMA-related endpoints
  http://oauth.net/core/1.0/... represents Oauth-related endpoints

Other example domain names stand for the following:

  http://copmonkey.com represents an UMA authorization manager (AM)
  http://schedewl.com represents an UMA host


1. User registers host at AM

Host registration is the act of an authorizing user introducing a host
to an authorization manager. Once registered, a host can request access
control decisions from the authorization manager for protected resources
being accessed by requesting services. Host registration can be achieved
through three-legged OAuth, with the host as the OAuth Consumer and the
AM as the OAuth Service Provider (SP).


1.1 User introduces host to AM

An authorizing user explicitly introduces a host to an AM via an
identifier that the host can be resolve via LRDD to an XRD. The XRD is
obtained by the host, and contains a link to the AM host root resource.
Example descriptor (all examples herein have namespaces suppressed for
brevity):

  <XRD>
    <Subject>http://copmonkey.com/</Subject>
    <Expires>2009-10-23T23:59:59Z</Expires>
    <Type>http://wg-uma.net/core/1.0/am</Type>
    <Link>
      <Rel>http://wg-uma.net/core/1.0/host</Rel>
      <URI>http://copmonkey.com/host/</URI>
    </Link>
    ...
  </XRD>


1.2 AM issues H->AM access token to host

The host resolves the URI of the AM host root resource, and sends an
HTTP POST request to that resource, to request creation of a new host
representing itself within AM. Example request:

  (connects to copmonkey.com:80)
  POST /host/ HTTP/1.1
  ...

Without any OAuth headers included in the request, AM responds with an
OAuth challenge. Example response:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: OAuth realm="copmonkey",
provider="https://copmonkey.com/oauth/"
  ...

  (entity contains human-readable page describing authentication
prerequisite)

The "provider" challenge (per OAuth discovery "sneak-peek") parameter
gives the URI of the OAuth provider used to authorize access to the host
container. The host performs LRDD discovery on this resource to resolve
its XRD, and it's obtained. Example descriptor:

  <XRD>
    <Subject>https://copmonkey.com/oauth/</Subject>
    <Expires>2009-10-23T23:59:59Z</Expires>
    <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type>
    <Link>
      <Rel>http://oauth.net/discovery/1.0/consumer-identity/static</Rel>
      <LocalID>53032297b44847ed</LocalID>
    </Link>
    <Link>
      <Rel>http://oauth.net/core/1.0/endpoint/initiate</Rel>
      <URI>https://copmonkey.com/oauth/initiate/</URI>
    </Link>
    <Link>
      <Rel>http://oauth.net/core/1.0/endpoint/authorize</Rel>
      <URI>https://copmonkey.com/oauth/authorize/</URI>
    </Link>
    <Link>
      <Rel>http://oauth.net/core/1.0/endpoint/token</Rel>
      <URI>https://copmonkey.com/oauth/token/</URI>
    </Link>
  </XRD>

In the descriptor, the consumer identity is statically allocated and
endpoints are established for OAuth protocol initiation, user request
authorization and access token issuance. How OAuth is negotiated is
out-of-scope for the UMA protocol, except that OAuth service discovery
is expected to be supported.

The host proceeds to negotiate the issuance of an access token by
initiating OAuth protocol flow (issuance of request token), user request
authorization (via authorization manager user interface to user), and
access token request.


1.3 Host requests creation of host resource (with signature)

Now that the host has an access token it can use to sign requests, it
re-issues the POST request from 1.2 above (now signed) to create a new
AM host resource:

  (connects to copmonkey.com:80)
  POST /host/ HTTP/1.1
  Authorization: OAuth realm="copmonkey",
oauth_consumer_key="53032297b44847ed",
    oauth_token="2f5fa6f0613942d9", oauth_signature_method="HMAC-SHA1",
    oauth_signature="...", oauth_timestamp="...", oauth_nonce="...",
    oauth_version="1.0"
  ...

The AM indicates the resource has been successfully created, with a new
identifier:

  HTTP/1.1 201 Created
  Location:
https://copmonkey.com/host/cbab2239-7528-4056-8aac-717d154e3972/
  ...


1.4 Host retrieves host resource descriptor

The host can now perform discovery on this new host resource (via LRDD
and GET request signed with OAuth) to get an XRD. Example descriptor:

  <XRD>
    <Subject>https://copmonkey.com/host/75284056/</Subject>
    <Expires>2009-11-22T23:59:59Z</Expires>
    <Type>http://uma-wg.net/core/1.0/host/instance</Type>
    <Link>
      <Rel>http://uma-wg.net/core/1.0/host/authorization/resource</Rel>
      <URI>http://copmonkey.com/host/75284056/authorization/</URI>
    </Link>
    <Link>
      <Rel>http://uma-wg.net/core/1.0/host/decision/resource</Type>
      <URI>https://copmonkey.com/host/75284056/decision/</URI>
    </Link>
  </XRD>

This descriptor contains an authorization resource that the host should
advertise to requesters (via XRDs for protected resources, discussed in
a later section) to use to acquire authorization. It also contains the
resource that the host can use to request access control policy
decisions.

The host can now report to the authorizing user that host registration
was successful.


2. Requester registers at host and gets R->H access token

In theory, any requester-to-host authentication token can be issued, for
example, a session cookie. In this example, an OAuth access token is
issued via a two-legged OAuth profile.

The requester attempts to access a protected resource at the host
anonymously and is challenged for OAuth authentication:

  (connects to schedewl.com:80)
  GET /calendar/ical/alice/public/travel.ics
  ...

Without any OAuth headers included in the request, an OAuth challenge is
returned. Example response:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: OAuth realm="schedewl",
provider="https://schedewl.com/oauth/"
  ...

  (entity contains human-readable page describing authentication
prerequisite)

The "provider" challenge parameter gives the URI of the OAuth provider
used to authorize access to the resource. The requester performs LRDD
discovery on this resource to resolve its XRD and it's obtained. Example
descriptor:

  <XRD>
    <Subject>https://schedewl.com/oauth/</Subject>
    <Expires>2009-10-23T23:59:59Z</Expires>
    <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type>
    <Link>
      <Rel>http://oauth.net/discovery/1.0/consumer-identity/static</Rel>
      <LocalID>86d2e3ae50f249c0</LocalID>
    </Link>
    <Link>
      <Rel>http://oauth.net/discovery/1.0/request-token/static</Rel>
      <LocalID>b73d827919874d58</LocalID>
    </Link>
    <Link>
      <Rel>http://oauth.net/core/1.0/endpoint/token</Rel>
      <URI>https://schedewl.com/oauth/token/</URI>
    </Link>
  </XRD>

The intent of this XRD is to represent two-legged OAuth, meaning that
there is no authorization of the OAuth request token by a user. In this
case, the host can issue an OAuth token to the requester by having the
requester retrieve the access token resource with a static consumer key
and request token. This is tantamount to a form of basic registration
for access credentials.

[Note: To my knowledge, there is not yet any 2-legged-OAuth XRD profile.
The example above is based purely on imagination. If you are aware of
such a profile, please let me know.]

The requester requests an access token from the host and the host issues
it. This access token is used to authenticate requests to the host by
the requester, but does not constitute authorization to access the
resource; authorization is provided by the AM in following steps.


3. Host refers requester to AM for authorization

[Note: An issue of possible MITM attack vector has been identified for
this section. This scheme will likely need to undergo some major
revision to mitigate it.]

The requester, with its R->H access token, attempts to request access to
the protected resource at the host:

  (connects to schedewl.com:80)
  GET /calendar/ical/alice/public/travel.ics
  Authorization: OAuth realm="schedewl",
oauth_consumer_key="86d2e3ae50f249c0",
   oauth_token="5cdd7b5c68e24908", oauth_signature_method="HMAC-SHA1",
   oauth_signature="...", oauth_timestamp="...", oauth_nonce="...",
   oauth_version="1.0"
  ...

The requester is authenticated by the host, but is not yet authorized by
the AM. The host requests a policy decision from the AM (interaction
documented in a following section), and the AM sends a "deny" decision,
and host responds to requester with a 403 status:

  HTTP/1.1 403 Forbidden
  ...

  (entity contains human-readable page describing authorization
prerequisite)

Using LRDD, the requester discovers the XRD descriptor for the protected
resource and obtains the descriptor. [Note: Whether a resource
descriptor is obtainable without a R->H access token is at the
discretion of the host.]

Example descriptor:

  <XRD>

<Subject>http://schedewl.com/calendar/ical/alice/public/travel.ics</Subject>
    <Expires>2009-10-23T23:59:59Z</Expires>
    ...
    <Link>

<Rel>http://uma-wg.net/core/1.0/requester/authorization/resource</Rel>

<URI>http://copmonkey.com/host/75284056/authorization/5cdd7b5c68e24908/</URI>
    </Link>
    ...
  </XRD>

In this descriptor, the requester discovers where it can obtain
authorization for access to the protected resource. The location is the
value that the AM originally provided to the host in the XRD for its
host resource, with an appended path segment indicating the identifier
that the host will use to identify the requester in access control
decision requests. This requester identifier is generated by the host,
and under the right conditions could simply be the access token the host
issued to the requester.


4. Host discovers required claims for access to resource

TBD


5. Requester registers with AM (if it hasn't already)

TBD


6. Host supplies required claims for access to resource

TBD


7. Host checks authorization resource for state

TBD


8. Host accesses resource

TBD


n. References [excerpt]

[LRDD] 
Hammer-Lahav
"Link-based Resource Descriptor Discovery 03", March 2009.
http://tools.ietf.org/html/draft-hammer-discovery-03

[XRD]
Hammer-Lahav, Noris
"Extensible Resource Descriptor (XRD) Version 1.0", October 2009
http://www.oasis-open.org/committees/download.php/34724/xrd-1.0-wd09.html

[HTTP]
Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee
"Hypertext Transfer Protocol — HTTP/1.1", RFC 2616, June 1999.
http://tools.ietf.org/html/rfc2616


________________________________________________________________________

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20091028/e4c36225/attachment-0001.html 


More information about the Wg-uma mailing list