Support for UMA, a.k.a. resource sets?

[akavel]

As far as I understand, OAuth provides "coarse grained" control over permissions, by which I mean it talks about "how to handle role-based access to resources". As such, it operates on pre-defined, "static" set of permissions (so called scopes).

UMA seems to be a semi-official (or at least the only official-looking one I could find) extension to OAuth 2.0, adding support for "fine grained", M:N sharing of resources. In simple words, it allows a scenario such as:

"Alice shares a folder of cat photos with Bob."

The UMA spec is obviously a bucketload of formalese blabbering, as specs of this world like to be, but if you squeeze it to get to the juice, it suddenly starts to show as rather simple, in my opinion. The core underlying "trick" seems to boil down to the following points:

• Authorization Server must store one extra persistent table, "resource_sets", where each row represents "an opaque pointer to some concrete resource(s) in RS". [For example, a row could represent Alice's folder named: "Rly funny CATS!!!1!1"] The columns would need to be more or less:
  • id — unique row ID in the AS
  • owner — Resource Owner of the resources [e.g. "alice"]
  • rs_id — ID provided by Resource Server (the "opaque pointer")
  • name — human-friendly name, also provided by RS [e.g. "Rly funny CATS!!!1!1"]
  • max_scopes — also provided by RS [e.g. "view", or "view add delete"]
  • a list of (user, scopes) pairs, dynamically managed by Resource Owner via some UI on AS. (This could be kept in a separate table if needed, implementation detail.) [e.g. ("bob", "view")]
• AS must also expose a REST API, through which Resource Server can create, edit, and delete resource_sets entries (more details in the UMA spec),
• and a UI, through which RO can add/remove users & permissions, i.e. (user, scopes) pairs, to owned resource_sets (or at least some REST endpoints, so that implementer could build UI on those).
• Resource Server must keep a mapping of: resource → rs_id;
• when some Client requests a resource in RS, the RS must find the rs_id, and ask AS what are allowed scopes for this rs_id, through some elaborate dance using Access Tokens etc.

So, I'd like to ask if you'd consider to support UMA in osin, to support such a "file-sharing-like" scenario over OAuth 2.0?

EDIT: Apparently there's UMA 2.0 now, IIUC the spec's link is: https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html (though now parts of it are split to separate documents, fortunately linked to from the main one... The general underlying idea seems to be still the same IIUC.)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/osin/issues/182#issuecomment-716196780): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[stlaz]

I think what you propose if far beyond what this library is trying to do, and that is to provide an implementation base of the core OAuth2 framework. I think it should still be possible to do what you're proposing with the library as is as the OAuth2 backend to the AS that you intend to develop.

Therefore keeping this issue closed.