Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returning RPT from Resource Server #355

Open
pedroigor opened this issue Sep 29, 2017 · 1 comment
Open

Returning RPT from Resource Server #355

pedroigor opened this issue Sep 29, 2017 · 1 comment

Comments

@pedroigor
Copy link

@pedroigor pedroigor commented Sep 29, 2017

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

This comment has been minimized.

Copy link

@xmlgrrl xmlgrrl commented Dec 23, 2017

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 xmlgrrl removed the V2.0 label Dec 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.