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

Make it possible to apply the protections of multiple AS permissions over a single resource set at the RS #95

Open
xmlgrrl opened this issue Jul 28, 2014 · 4 comments
Labels
APIsec Related to API security use cases core Related to (original UMA1) core spec scope; may use obsolete language fedauthz Related to UMA2 Federated Authorization

Comments

@xmlgrrl
Copy link

xmlgrrl commented Jul 28, 2014

This is a desirable feature particularly in enterprise settings; Gluu has mentioned this as a potential benefit of UMA for the enterprise. However, it brings up questions of how to how to manage multiple "PATs' worth" of protection over a resource set, how to register a resource set in multiple locations, how to combine permissions deriving from multiple "bearer"-type RPTs, and eve how to combine multiple RPT types.

@mmachulak
Copy link

I think that this is a very valuable feature and I am in favour of discussing it. Also, you may want to take a look at some preliminary write up about this here (Section 2.4): http://www.cs.ncl.ac.uk/publications/trs/papers/1165.pdf (5 years old, though)

@xmlgrrl xmlgrrl added this to the V1.0 Public Review prep milestone Aug 6, 2014
@jmdacruz
Copy link

jmdacruz commented Aug 8, 2014

I'm also in favor of discussing this. I'm personally more interested in an "OR" type of trust decision between the AS (e.g., only one of the AS that has registered the resource is needed for decision making) because this is interesting from the failover/contextual (e.g., one of the AS is not reachable) point of view, but I can also think about "AND" scenarios (e.g., the RS needs to evaluate trust based on all of the AS in which it is registered)

@xmlgrrl xmlgrrl removed this from the V1.0 Public Review prep milestone Dec 11, 2014
@xmlgrrl
Copy link
Author

xmlgrrl commented Dec 11, 2014

We agreed on UMA telecon 2014-12-11 that this is not critical for V1.0.

@xmlgrrl xmlgrrl removed the tests label Jul 30, 2015
@xmlgrrl xmlgrrl added the V1.1 label Aug 30, 2015
@xmlgrrl xmlgrrl added APIsec Related to API security use cases fedauthz Related to UMA2 Federated Authorization labels Jan 27, 2016
@xmlgrrl
Copy link
Author

xmlgrrl commented Dec 23, 2017

Note that #260 is relevant to this issue. (I'm going to remove the "V1.1" label since we didn't publish a V1.1.)

@xmlgrrl xmlgrrl removed the V1.1 label Dec 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
APIsec Related to API security use cases core Related to (original UMA1) core spec scope; may use obsolete language fedauthz Related to UMA2 Federated Authorization
Projects
None yet
Development

No branches or pull requests

3 participants