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
https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-07.h...:
"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
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