Given that the RPT is somewhat equivalent to an OAuth2 access token, the
OAuth2 best practice is to return the set of scopes that were met as part
of the request, and also inform the client of which scopes where granted.
This becomes a little more problematic for the scopes defined by the
permissions_ticket because the client doesn't know what they are. If we
allow the "partial scopes" response, it will be possible for the client to
successfully get an RPT that does not provide it the access it needs to a
particular resource.
Take the following example:
Alice has a photo album that Bob is trying to access. Bob's client makes
the request to Alice's album and the RS requests the AS to generate a
permission_ticket with view,edit scopes for the resource. Bob's client
presents the permission_ticket to the AS and goes through some claims
negotiation. The result of the set math is that Bob's client gets 'edit'
scope but not 'view'. If the AS issues the RPT with just the 'edit' scope,
the it's unlikely that Bob's client will work as it really wanted 'view'
access.
I'm becoming more convinced that the responsibility for the scopes
necessary to issue the RPT must lie with the RS and NOT the AS. If the RS
is asking for too many scopes up front, then Bob's experience will have a
lot of overhead just to be able to view the photos. On the other hand, if
the RS asks for just the scopes needed and the AS overrides that decision
by returning less, the overall experience will break.
Hopefully that makes sense:)
Thanks,
George
On Wed, Jan 25, 2017 at 12:37 PM James Phillpotts <
james.phillpotts@forgerock.com> wrote:
Right, I see. Maybe an example would help?
On 25 January 2017 at 17:35, Eve Maler wrote:
Hey, I'm always up for a good disquisition ("a long or elaborate essay or
discussion on a particular subject"). :-) In fact, I did try new wording in
rev 13 already based on the fact that with our set math I couldn't make
heads or tails of the MUST wording (note that this comes after the new
agreed wording
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html#authorization...
about the AS having a choice to respond with an RPT or a failure if the
scopes satisfied are less than the scopes requested):
"Note: While a reasonable approach for most scenarios is to implement the
classic security stance of default-deny ("everything that is not expressly
allowed is forbidden"), corner cases can inadvertently result in
default-permit behavior. For example, it is insufficient simply to assume
that all resources have some non-zero set of claims required for access,
and then accept an empty set of supplied claims as sufficient for access."
This was in order to advise anyone starting to build an AS from scratch
about some of the best practices and subtleties of policy engine and access
control work. Thoughts?
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl |
Twitter: @xmlgrrl
On Wed, Jan 25, 2017 at 8:32 AM, James Phillpotts <
james.phillpotts@forgerock.com> wrote:
Hi all,
Thanks for the reminder to send this email Eve! ;)
The paragraph in question is:
The authorization server MUST use a default-deny authorization assessment
model in adding permissions to RPTs, that is, "everything that is not
expressly allowed is forbidden" for resources for which resource servers
have requested access permission on behalf of clients. Exercise caution in
implementing default-deny because corner cases can inadvertently result in
default-permit behavior. For example, it is insufficient simply to assume
that all resources have some non-zero set of claims required for access,
and then accept an empty set of supplied claims as sufficient for access.
I'm not convinced that this paragraph is really very useful, but that may
be because it isn't clear at what level the 'deny' is relating to in this
context - is it on a per-resource, per-scope, or an RPT level?
If per-resource, I think this is a reasonable thing to express, but I'm not
sure the paragraph does a particularly good job of it.
If per-scope, does this only apply to additional scopes requested by the
client?
If RPT, then I don't think the idea is correct, as the RPT shouldn't be
denied based on the outcome of a particular policy for a particular
resource.
On one of the calls I thought someone had mentioned that the RPT should
only be granted if all of the scopes requested in the permission ticket
were able to be granted, but I think it should be perfectly reasonable to
grant a subset - e.g. if ticket requests view, edit for resource A and view
for resource B but all that can be granted is view for A, then that is a
perfectly reasonable response?
This was partly triggered by Mike's suggestion of patterned URIs, where I
was thinking about the RS wants *either* view on A, view on B or view on C,
because it knows that the actual requested URL is covered by all 3 of those
registered resource sets (although as per other email, I wouldn't like that
to be a pattern).
Sorry if this is slightly rambling.
Cheers,
James
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Distinguished Engineer
Identity Services Engineering, AOL Inc.
Mobile:+1-703-462-3494 Office:+1-703-265-2544