[WG-UMA] For email and Oct 9 discussion/closure: eager permission registration (issues 88 and 99)

Eve Maler eve at xmlgrrl.com
Tue Oct 7 09:51:54 CDT 2014


On 26 Sep 2014, at 10:59 AM, Eve Maler <eve at xmlgrrl.com> wrote:

> Here is a tweaked proposal for eager permission registration, borrowing from/inspired by earlier text that let the AS implementation choose its own strategy for RPT management. It does need a bit more discussion; see below! But I think it's a lot closer...
> 
> 	Eve
> 
> On 14 Sep 2014, at 11:31 PM, Eve Maler <eve at xmlgrrl.com> wrote:
> 
>> As promised, Thomas and I wanted to present y'all with this proposal based on the last couple of weeks of discussion. Some commentary:
>> 
>> This solves for eager permission registration and, thus, consolidation of the RPT endpoint and the authorization request endpoint. See the new version of the UMA-flow.pptx deck to see the consequences of how everything gets shortened up and reordered in this consolidation.
>> It also throws in a little wording (in 3.4) to explain how lazy binding of each RPT to each RS works. (Eager RS binding of RPTs may be beside the point now that RPTs are issued lazily themselves. Thoughts?)
>> There is no optionality; this approach is very spare and clean. Thus:
>> When a client approaches an RS with no RPT:
>> the RS gets a permission ticket for it;
>> the client is expected to show up at the AS still with no RPT;
>> and the AS is expected to issue a new RPT for it in issuing and associated the new authz data that goes with that ticket.
>> When a client approaches an RS with an RPT that turns out to have insufficient authz data:
>> the RS gets a permission ticket for it;
>> the client is expected to show up at the AS with that RPT in tow;
>> and the AS is expected to issue the new authz data that goes with that ticket and associate it with the same RPT.
>> This way, the client is (sort of) in control of whether it wants to manage lots of RPTs or just one big one (for this RS). Of course, as we already note in Section 1.3.3, an RPT is already a tuple that is specific to a requesting party, so the client is still managing one RPT (or more RPTs, according to this proposal!) per RqP.
> 
> Now there is optionality, specifically around the ability of the AS to return either the same RPT or a new one, and to maintain the validity of the old RPT or invalidate it as it sees fit (new proposal to be discussed).
> 
>> N.B.: We may need some error conditions for RPT presence/absence in the client's request to the AS (Bad Request and an UMA error code?) to go along with the above, but let's validate the proposal first...
> 
> The previously proposed text stands except where new text is provided just below the old text. I've tried to fill in new error text etc. where needed, as well, so that the proposal is more complete.
> 
>> 
>> ====
>> Section 1.4
>> 
>> Remove:
>> 
>> rpt_endpoint
>> 
>> REQUIRED. The endpoint URI at which the client asks the authorization server for an RPT. Usage of this endpoint is defined by Section 3.4.1. A valid AAT MUST accompany requests to this protected endpoint.
>> 
>> Change from…
>> 
>> authorization_request_endpoint
>> 
>> REQUIRED. The endpoint URI at which the client asks to have authorization data associated with its RPT. Usage of this endpoint is defined in Section 3.4.2. A valid AAT MUST accompany requests to this protected endpoint.
>> 
>> …to:
>> 
>> authorization_request_endpoint
>> 
>> REQUIRED. The endpoint URI at which the client asks for authorization data and for an RPT as necessary. Usage of this endpoint is defined in [Section xref]. A valid AAT and a permission ticket MUST accompany requests to this protected endpoint.
>> 
>> Remove:
>> 
>> "rpt_endpoint":"https://as.example.com/client/rpt_uri",
>> 
>> Section 3
>> 
>> Change from…
>> 
>> The interactions are as follows. Each interaction MAY be the last, if the client chooses not to continue pursuing the access attempt or the resource server chooses not to continue facilitating it.
>> 
>> The client attempts to access a protected resource.
>> If the access attempt is unaccompanied by an RPT, the resource server responds immediately with an HTTP 401 (Unauthorized) response and instructions on where to go to obtain one.
>> If the access attempt was accompanied by an RPT, the resource server checks the RPT's status.
>> If the RPT is invalid, the resource server responds with an HTTP 401 (Unauthorized) response and instructions on where to go to obtain a token.
>> If the RPT is valid but has insufficient authorization data, the resource server registers a suitable requested permission on the client's behalf at the authorization server, and then responds to the client with an HTTP 403 (Forbidden) response and instructions on where to go to ask for authorization.
>> If the RPT is valid, and if the authorization data associated with the token is sufficient for allowing access, the resource server responds with an HTTP 2xx (Success) response and a representation of the resource.
>> If the client (possessing no RPT or an invalid RPT) received a 401 response and an authorization server's location, after looking up its configuration data and endpoints as necessary, it requests an RPT from the RPT endpoint of the authorization API.
>> If the client (posessing a valid RPT) received a 403 response and a permission ticket, it asks the authorization server for authorization data that matches the ticket using the authorization request endpoint of the authorization API. If the authorization server needs requesting party claims in order to assess this client's authorization, it engages in a claims-gathering flow.
>> If the client does not already have an AAT at the appropriate authorization server to be able to use its authorization API, it first obtains one.
>> 
>> 
>> …to:
>> 
>> The interactions are as follows. The recipient of each request message SHOULD respond unless it detects a security concern, such as a suspected denial of service attack that can be mitigated by rate limiting.
>> 
>> The client attempts to access a protected resource.
>> If the access attempt is unaccompanied by an RPT, the resource server registers a suitable requested permission on the client’s behalf at the authorization server, and then responds to the client with an HTTP 403 (Forbidden) response, a permission ticket, and instructions on where to go to obtain an RPT and authorization data.
>> If the access attempt is accompanied by an RPT, the resource server checks the RPT's status.
>> If the RPT is invalid, or if the RPT is valid but has insufficient authorization data, the resource server registers a suitable requested permission on the client’s behalf at the authorization server, and then responds to the client with an HTTP 403 (Forbidden) response, a permission ticket, and instructions on where to go to obtain a valid RPT and authorization data for it.
>> If the RPT is valid, and if the authorization data associated with the token is sufficient for allowing access, the resource server responds with an HTTP 2xx (Success) response and a representation of the resource.
>> If the client received a 403 response and a permission ticket, it asks the authorization server for authorization data that matches the ticket using the authorization request endpoint of the authorization API, and for an RPT as necessary. If the authorization server needs requesting party claims in order to assess this client's authorization, it engages in a claims-gathering flow.
>> If the client does not already have an AAT at the appropriate authorization server to be able to use its authorization API, it first obtains one.
>> 
>> Section 3.1.1
>> 
>> Change from…
>> 
>> If the client does not present an RPT with the request, the resource server returns an HTTP 401 (Unauthorized) status code and providing the authorization server's URI in an "as_uri" property to facilitate authorization server configuration data discovery, including discovery of the endpoint where the client can request an RPT (Section 3.4.1).
>> 
>> For example:
>> 
>> HTTP/1.1 401 Unauthorized
>>    WWW-Authenticate: UMA realm="example",
>>     host_id="photoz.example.com",
>>     as_uri="https://as.example.com"
>>    ...
>> 
>> …to:
>> 
>> If the client does not present an RPT with the request, the resource server uses the protection API to register a requested permission with the authorization server that would suffice for that scope of access (see Section 3.2). It then responds with the HTTP 403 (Forbidden) status code, providing the authorization server's URI in an "as_uri" property in the header and the permission ticket it just received from the AM in the body in a JSON-encoded "ticket" property.
>> 
>> For example:
>> 
>> HTTP/1.1 403 Forbidden
>> WWW-Authenticate: UMA realm="example",
>>   host_id="photoz.example.com",
>>   as_uri="https://as.example.com"
>> 
>> {
>> "ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
>> }
>> 
>> Section 3.1.2
>> 
>> Change from…
>> 
>> If the RPT is invalid, the resource server applies UMA protection by returning an HTTP 401 (Unauthorized) status code and providing the authorization server's URI in an "as_uri" property in the header, similarly to the case where no RPT was presented.
>> 
>> If the RPT is valid but has insufficient authorization data for the type of access sought, …
>> 
>> …to:
>> 
>> If the RPT is invalid, or if the RPT is valid but has insufficient authorization data for the type of access sought, …
>> 
>> Section 3.2
>> 
>> Change from…
>> 
>> In response to receiving an access request accompanied by an RPT that has insufficient authorization data, the resource server uses the protection API's permission registration endpoint to register a permission with the authorization server that would be sufficient for the type of access sought.
>> 
>> …to:
>> 
>> The resource server uses the protection API's permission registration endpoint to register a permission with the authorization server that would be sufficient for the type of access sought.
>> 
>> Section 3.4 (recommend removing internal 3.4.1 and 3.4.2 headers)
>> 
>> Change from…
>> 
>> The authorization server issues client credentials to the client. It is OPTIONAL for the client credentials to be provided dynamically through [DynClientReg]; alternatively, they MAY use a static process.
>> The client acquires an AAT.
>> The client uses the authorization API to acquire an RPT. See Section 3.4.1 for more detail.
>> The client uses the authorization API to ask for authorization, providing the permission ticket it got from the resource server. The authorization server associates authorization data with the client's RPT based on the permission ticket, the resource owner's operative policies, and the results of any claims-gathering flows. See Section 3.4.2 for more detail.
>> 
>> …to:
>> 
>> The authorization server issues client credentials to the client. It is OPTIONAL for the client credentials to be provided dynamically through [DynClientReg]; alternatively, they MAY use a static process.
>> The client acquires an AAT.
>> The client uses the authorization API to acquire an RPT and to ask for authorization data, providing the permission ticket it got from the resource server. The authorization server associates authorization data with the RPT based on the permission ticket, the resource owner's operative policies, and the results of any claims-gathering flows.
>> 
>> Replace all of 3.4.1 and first paragraph of 3.4.2 as follows (further revisions to come if we agree on eager RS binding of RPTs):
>> 
>> Once in possession of a permission ticket and an AAT for this authorization server, the client asks the authorization server to give it suitable authorization data for the sought-for access. It performs a POST on the authorization request endpoint, supplying its own AAT in the header and with a JSON object in the body with the property “ticket” containing the ticket as its value, as well as the property “rpt” containing its RPT presented in the access attempt that resulted in receiving this permission ticket as its value, if any was indeed presented.
> 
> I think we need to discuss this bit about providing the RPT in the request for authorization data, at least. What happens if the client provided an RPT to the RS but then doesn't provide an RPT to the AS in asking for authz data? What if it provides the wrong one? Should we tell it never to bother providing the RPT to the AS, so that it ALWAYS gets a fresh RPT?? Should we make it optional for the client to pass along the RPT??
> 
>> 
>> Change from…
>> 
>> The authorization server MUST base the granting of authorization data to RPTs on user policies. The nature of these policies is outside the scope of UMA, but generally speaking, they can be thought of as either independent of requesting-party features (for example, dictating access based on time of day or client identity) or dependent on requesting-party features (for example, dictating access based on whether they are over 18 or present a certain identifier). Such requesting-party features can potentially be collected in a claims-gathering flow.
>> 
>> Once the authorization server associates authorization data with the RPT, it responds with an HTTP 201 (Created) status code. If the authorization server chooses to invalidate the original RPT in response to the request and to issue a new one to be associated with the resulting authorization data, it MUST provide that refreshed RPT in the body.
>> 
>> Example when the authorization data has been added and the RPT has been refreshed:
>> 
>> …to:
>> 
>> The authorization server bases the issuing of authorization data on resource owner policies. The nature of these policies is outside the scope of UMA, but generally speaking, they can be thought of as either independent of requesting-party features (for example, dictating access based on time of day or client identity) or dependent on requesting-party features (for example, dictating access based on whether they are over 18 or present a certain identifier). Such requesting-party features can potentially be collected in a claims-gathering flow.
>> 
>> Once the authorization server issues the requested authorization data, it associates it with an RPT and responds to the client with an HTTP 201 (Created) status code containing that RPT. If the client presented no RPT in the request for authorization data, the authorization server creates a new RPT and returns it. If the client presented an RPT in the request, the authorization server adds to the authorization data of that RPT and returns it in the response. An RPT and all authorization data associated with it are bound to a single resource server by virtue of the permission registration activities that drive ticket creation and, ultimately, RPT creation.
> 
> Change the last paragraph to:
> 
> Once the authorization server issues the requested authorization data, it associates it with an RPT and responds to the client with an HTTP 201 (Created) status code containing that RPT. If the client presented no RPT in the request for authorization data, the authorization server creates a new RPT and returns it. If the client presented an RPT in the request, the authorization server returns the RPT with which it associated the authorization data. Note: It is entirely an implementation issue whether the returned RPT is the same one that appeared in the request or a new RPT, and it is also an implementation issue whether the AS chooses to invalidate or retain the validity of the original RPT in this case.
> 
> [Stated this way to avoid "MAY" language, since it's not a matter for testable assertions and interop feature tests, but rather non-normative advice to implementors.]
> 
>> 
>> Example:
>> 
>> Change from (this wording seems to need some cleanup around “authorization” vs. “permission” — not strictly related to the RPT endpoint stuff! — is it okay to consider a backwards-incompatible change to this error code for this reason?)…
>> 
>> not_authorized_permission
>> 
>> The client is definitively not authorized for this authorization according to user policy. The authorization server responds with the HTTP 403 (Forbidden) status code.
>> 
>> …to:
>> 
>> not_authorized
>> 
>> The client is definitively not authorized for access. The authorization server responds with the HTTP 403 (Forbidden) status code.
>> 
>> Section 5.2
>> 
>> Change from…
>> 
>> An RPT MAY be issued without requiring explicit use of the RPT endpoint or presentation of an AAT in any RPT request.
>> 
>> …to:
>> 
>> An RPT MAY be issued without requiring explicit use of presentation of an AAT in any RPT request.
>> 
> 


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20141007/4dd34ecb/attachment-0001.html>


More information about the WG-UMA mailing list