Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Optimizing for resource "baskets" #31
The following issue was discussed on [2010-04-22|http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-04-22]:
Eve advocates that we keep things very simple for how to configure resources and policies into baskets: She imagines that users will likely want all resources in a basket to inherit whatever the basket's policy is. She has been conceiving of baskets as a special category of resource that is hosted by a host that has a special tight relationship with the AM.
She guesses that the whole topic of baskets doesn't really have protocol implications per se, but does have some fairly deep application implementations. Or does it have protocol implications? George asks if a requester has already proved that it has a right to get to the basket, can it proceed to each of the linked resources (on whatever hosts) and get immediate access with the token it was already given? Paul believes that the procedure for having the requester prove itself at each host should remain in place, but that it's possible some of these interactions can, on a per-host basis, be optimized through scope-parameter tricks when the AM issues the first token involving each host.
George wonders if this is missing an opportunity for truly intuitive and useful optimization on the requester's part when accessing all the things in a basket. Should it be possible for the requester to approach each host/protected resource in a basket with some kind of intermediate token saying that it's asking for access as part of a "basket request", so that it doesn't have to re-qualify over and over at the AM, by (e.g.) presenting the same set of claims? Then again, if inheritance works such that the "strongest" policy (according to whose definition??) is inherited by everything in the basket, that could be valuable.
Added on 6 Oct 2011: Would the OpenID Connect solutions for distributed and aggregated claims suggest a canonical way for an AM to handle baskets? Is it worth profiling OpenID Connect for such behavior as it relates to an AM?
In case of aggregation of resources (Basket), the AM must provide a specific endpoint which is able to enforce the policy for the requester for the specific collection of resources. In this case, the Requester must interact with the AM first, and then with the resources, in order to provide the list of resources along with the access token.
The following example shows a possible AM response:
Could we perhaps extend the OpenID Connect mechanisms for "distributed claims" to apply to "distributed resources of any kind", so that we can simply UMA-protect a resource that unrolls to point to more resources? The description of aggregated and distributed claims is here:
Here's how distributed claims look:
The "claim" language isn't quite right for us, and some of the other assumptions might need to be tweaked too, but the structures look similar.
Would we need a "relative" access token, or could we just treat each resource as UMA-protected (or public, or OAuth-protected, or whatever) separately? Any resources that are protected by the same UMA AM could be protected with policies that are related to each other (even literally "relative"), but this could be a UX feature rather than something that has to be baked into UMA itself.
OpenID Connect's "distributed claims" model represents a good starting point to extend UMA to provide an aggregation of resources approach. The main different is that Claims are simply protected. In UMA, a resource could be protected for different purposes, that means we can have many policies for the same resource. For the same reason I was thinking to a "basket collector" endpoint at AM to descriminate the policy that match with a particular purpose and the same time return a list of resource endpoints along with access tokens as OpenID Connect does.
From UMA telecon 2012-01-19: Kevin asks if there was any way for two AMs to talk to each other, since they probably already know who each were. Thomas comments that this is like Certificate Authorities (CA) in the PKI world where they know each other and can even establish a bridge CA cert. Domenico comments that UMA should leverage the distributed claims within OpenID. The Authorizing User sets policies for the basket, and the AM will then provide an API endpoint to the requester to access the basket. Kevin asks if this would mean that the AM needs to know all the resources kept at a host.
referenced this issue
Oct 31, 2014
In our UMA 2.0 work, we have gotten more familiar with the challenges of how an API publisher (RS) needs to manage its internal view of complex resources vs. what may be an authorization server's more simple view, currently represented with the following language in UMA 2.0 Core (rev 10):
"The resource server MAY register for protection a single resource that, from its perspective, has multiple parts, or has dynamic elements such as the capacity for querying or filtering, or otherwise has internal complexity. The resource server alone is responsible for maintaining any required mappings between internal representations and the resource identifiers and scopes known to the authorization server. Because access attempts on resources by clients are resource identifier-unaware, the process of making a permission request may also require interpretation by the resource server in order to establish a suitable resource identifier, resource owner, and authorization server."
Part of a resource-basket solution likely has to do with what we have been calling "set math": The dance among the client, RS, and AS (and -- end to end -- the RO and RqP) to attempt to acquire permissions for the right resource(s) and scopes(s) given the principles of least privilege, efficiency, and access control. This occurs in band in the protocol. We are converging on new solutions here.
Another part of a solution could possibly appear out of UMA's scope in some fashion, to inform the AS of resource complexity where that is desirable. This has come up in the context of the FHIR API / the HEART WG.