Let me see if I understand.

If "there is no need for RO approval", I'm assuming there's no need to lodge a new policy in place; you can "check if a requesting party is allowed or not to access the resource" on the back end and successfully locate an existing policy that says sharing okay. Maybe it's an enterprise (legal person/non-human) RO, and these are enterprise policies? In any case, pre-provisioned policy or "proactive sharing" would be just as typical a flow choice as "reactive sharing"/access approval.

If "there's no need for interactive claims gathering", it sounds like you're using claims pushing ("the token the client has"), such that the client itself is able to identify the requesting party to the authorization server sufficiently.

It sounds like you're looking for a way that the RS can present a token-equivalent endpoint to the client. The client pushes a claim token about the RqP to the RS, the RS turns around and gives it to the AS perhaps along with additional runtime/contextual data as input to policy, the AS does all the authorization assessment, the AS gives the RS an RPT on behalf of the client, and the RS passes it along.

Some thoughts:
  • A few months ago a couple of university students reached out to me to ask why the permission ticket exists. They felt it was inefficient and had no security or UX rationale and wondered why we didn't simply "have the RS redirect the client to the AS" (I wasn't sure if that meant redirecting the RqP). Here's a boiled-down list of my rationale in response: It exists to enable a) correlation across looping authorization assessment scenarios, b) support for both claim pushing and claim interaction scenarios, and c) AS discovery by party B's client (giving freedom to the resource owning/serving side to choose multiple AS's) -- though this last one is the weakest in the face of a token-equivalent endpoint. Are you saying the use case you want to optimize for is to have a policy in place that matches the resource request, or alternatively it's always a definitive failure?
  • In your use case, are the AS and RS colocated? The prevalence of this circumstance in today's OAuth world is one of the reasons we carved off the protection API (FedAuthz) from the extension grant (Grant) and made the former optional. (Admittedly, the RS permission ticket bootstrapping step still doesn't go away.)
  • How complete would the functionality RS token-equivalent endpoint have to be? Presumably it just passes values through to the AS. Which values should the RS not be exposed to as security/privacy considerations? At least the claim token and PCT, I think.
  • How important is the runtime/contextual data element? I've discussed this casually with some people in the past, and so far we have relegated it to one of the following: a) extension data that could potentially travel along the RS's permission request message channel, so that the AS could consider it as part of its authorization assessment, or b) "edge" authorization that the RS performs on its own, as part of what we call the "Adrian clause" (in FedAuthz Sec 1.4: "However, the resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria.").

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Fri, Sep 1, 2017 at 3:39 AM, Pedro Igor Silva <psilva@redhat.com> wrote:
Hello,

I have an use case where resources from a UMA protected resource server don't require issuance of permission tickets. There is no need for RO approval neither claims gathering flow. But just check if a requesting party is allowed or not to access the resource.

I was wondering if I could enable a RS to act as a broker in a way that it could exchange the token the client has with a RPT and then return the RPT to the client. Subsequent requests from client will then use the RPT returned by the RS to access protected resources.

With this scenario I'm looking for:

* Avoid unnecessary round trips between clients and AS in order to obtain a RPT when a permission ticket is not necessary.

* Allow RS to push additional claims to AS with runtime/contextual data and evaluate policies based on these claims.

Any thoughts ?

Regards.
Pedro Igor 



_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma