Hello, Eve. Answers inline ...

On Fri, Sep 1, 2017 at 5:22 PM, Eve Maler <eve@xmlgrrl.com> wrote:

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.

Now that you mentioned "proactive" and "reactive", I think I can explain better what I want to achieve.

If I understood correctly, what I'm looking for is a "proactive" approach, where the RS has some built-in policies that rule access to some resources. As an example, "Alice Resource" and "View Scope" is associated with a general policy that only allow access if the RqP is the resource owner. I don't really care about starting authorization flows to allow access by third parties. Neither allow users to change this policy.

 

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.

Yes.

 

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.

Yes, exactly. The idea is return the RPT in a similar way as permission tickets, via WWW-Authenticate header.

My main objective is support this use case without loose UMA nature and avoid end up with some different endpoint or authorization flow. For instance, we have in Keycloak a Entitlement API that provides a way to obtain RPTs without permission tickets, a simple and single request/response interaction with the AS. I want to get rid of that and follow UMA standard as much as possible.

 

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?

I fully understand the idea behind permission tickets and it is one of the main concepts that make UMA so great. I'm not discarding permission tickets, but just trying to still follow UMA concepts when dealing with use cases that don't really need a permission ticket.

 

• 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.)

Yes, they are colocated. Even clients are colocated in some cases. All of them part of the same realm/security domain.

 

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

My initial idea for this "RS token-equivalent" endpoint is very simple. It would basically return a RPT via a WWW-Authenticate header. Not sure if this is the best approach, but it is at least aligned with how clients interact with RS when doing the usual UMA flow.

 

• 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,

Yeah, that is how I think a RS could push runtime/contextual data when using permission tickets and the usual authorization flow. When asking for a ticket, the RS could also send/associate any additional data that he wants to make available to the AS when evaluating policies. For instance, "bank.account.withdraw: 200".

 

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

Yeah, that is what I'm looking for. Is not enough to say that you have permission to a resource, but you might also need to check the circumstances that make this permission valid. For instance, I could have a RPT like that:

permissions: [

    {

        resource_id: 12345

        context: {

            bank.account.withdraw: 200

        }

    }

]

The RS would need to make sure that any request trying to withdraw money from some bank account is <= 200, for instance.

 

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