Returning RPT from Resource Server

[pedroigor]

Overview

This issue is a follow up of a discussion [1] started on WG-UMA mailing list about use cases where the RS is protecting its own resources and privacy is not really a concern. For these use cases there is an assumption that every single protected resource have the RS itself as RO.

This assumption highlights some important points that should be considered on how to address such use cases using UMA given that:

• Privacy is not a concern, but security.
• Permission Ticket and all it represents is not really necessary given that there is no need to store permission requests neither manage approvals from resource owners (e.g.: some entity other than RS whose resources are protected by this same RS).
• Permission Ticket introduce unnecessary round trips between Client, RS and AS.
• Resource Server should still be able to pass additional data to AS when obtaining a RPT where this data should be available to the policies associated with the resources being requested.
• Resources should still be opaque to Clients when seeking access to a protected resource. Just like it stands today, where the permission ticket returned back from a RS is completely opaque to the Client requesting a resource.

Another important consideration to be made is that both RS and AS are colocated. In some cases, even the client could be within the same realm or security domain as RS and AS.

Considering all that, this issue aims to bring to discussion some sort of extension that could help address such use cases while still using most of UMA constructs and definitions.

I'm glad to come up with some suggestions about how to address some of the issues pointed out here if you think that what have been said so far makes sense and worthy to invest some time.

It would be nice to come up with something that could leverage UMA and support use cases other than those related with privacy. Nowadays, there are a lot of demand for protecting microservices or even resources in a monolithic application, where token-based authentication is becoming a very attractive solution for those looking not only for authentication but, specially, authorization.

References

[1] https://kantarainitiative.org/pipermail/wg-uma/2017-September/005320.html

[xmlgrrl]

Since this is intended to be an "extension" discussion (as documented in the Disposition of Comments), at this point I'll remove the "V2.0" label.

[xmlgrrl]

This is an extension that Keycloak implements but has not been standardized, either as a separate extension spec or as an UMA RFE. See Pedro's announcement to the list here. We have discussed the extension in calls (e.g. in UMA telecon 2018-11-02).

[pedroigor]

@xmlgrrl Hi @xmlgrrl. Closing as out of date.