Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizing for resource "baskets" #31

Open
xmlgrrl opened this Issue Oct 7, 2011 · 6 comments

Comments

Projects
None yet
2 participants
@xmlgrrl
Copy link

xmlgrrl commented Oct 7, 2011

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?

@domcat

This comment has been minimized.

Copy link

domcat commented Jan 18, 2012

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.
In a typical scenario, an Authorizing User defines a Connection Policy for an aggregation of resources, including ACTIONS, SUBJECTS and ACCESS RESTRICTIONS (trusted claims). As result of this policy definition, the AM publishes a basket at a specific endpoint (e.g. Basket Collector).
The Requester, in someway, obtains the link for the Basket Collector and attempts to access to the Collector. The AM applies the policy enforcement and grant access to the "basket" which includes the list of the protected resources. The Requester iterates the access to the resources in the basket using the relative access token.

The following example shows a possible AM response:
{
"_protected_resources": {
"res1": {"host_res": "https//info.datacredit.com/risk/score/", "actions": {"read"}, "access_token": "adfjakfyelfjdl"}
"res2": {"host_res": "https//info.bankone.com/account/iban", "actions": {"read"}, "access_token": "llgfiligjhfaluw"}
}

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Jan 18, 2012

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:

http://openid.net/specs/openid-connect-messages-1_0.html#anchor18

Here's how distributed claims look:

"_claim_sources": {
"src1": {"endpoint": "https://bank.example.com/claimsource"},
"src2": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"}
}

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.

@domcat

This comment has been minimized.

Copy link

domcat commented Jan 19, 2012

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.

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Jan 21, 2012

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.

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Jan 4, 2017

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):

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html#resource-scope-interpretation

"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.

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Mar 13, 2017

Per UMA telecon 2017-03-09: Eve proposes Option 1 from her email (close with no action). James groks. (smile) Let's close, put the extension label on it, and put the email proposal into the issue.

@xmlgrrl xmlgrrl closed this Mar 13, 2017

@xmlgrrl xmlgrrl removed the V2.0 label Mar 15, 2017

@xmlgrrl xmlgrrl reopened this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.