User-Managed Access (UMA) standard

[jawadatgithub]

Any plans for supporting User-Managed Access (UMA) standard?

ref:
https://docs.kantarainitiative.org/uma/rec-uma-core.html

[leastprivilege]

I never looked into the UMA spec - but in your words - what would it add to identityserver?

[jawadatgithub]

I understood from UMA specs, that it can integrate perfectly with OAuth2, in similar sense OIDC extended OAuth2 with user identity by introducing userinfo endpoint, UMA extends OAuth2 with user-access permissions/management by introducing 2 endpoints that consume access-token in Bearer format: first endpoint to register user permission and second endpoint retrieve user permission.

so if that's included in IdentityServer3, the pipeline flow can be illustrated like this:

OIDC -> OAuth2 -> UMA

in other words, as OIDC came on top of OIDC, UMA goes under/below OAuth2 :)

if you want quick look about the 2 endpoints without spending a lot of time reading the specs then please check below section of the specs:

https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.2.1

[leastprivilege]

..and what's the benefit?

[jawadatgithub]

I agree that IdentityServer3 built as OIDC and OAuth2 provider. but I don't understand why it would be bad idea to enrich it with user-managed access.

UMA resolve big issue and misconception in OIDC & OAuth2 uses. a lot of people inject fine grained permissions in hacky way in access-token or identity token claims, and you fully aware that OAuth2 scopes only designed for coarse-grained permissions. so by embedding UMA in idsrv3, the community wouldn't be lost anymore on how to manage user permissions in fine-grain style.

even this point might not help convincing you, a couple of OIDC providers already embedded UMA. but since I love idsrv3 and see it as the best provider I think embedding UMA will make it even greater.

I am aware how busy you are in delivering idsrv4, and I wish I had time to contribute myself since I followed the project about year ago, but currently my schedule is fully allocated till June.

thanks for taking the time to read my words.

[leastprivilege]

No thats fine - as I said I never spent time with UMA. It sounds interesting - but yeah - right now I have no spare time for that.

Also - I had a brief look at it - and it looks like this would be a separate service anyways - so nothing necessarily "inside" identityserver - right?

[jawadatgithub]

I can't confirm now if its feasible to make it as separate service (I need dig deeper), but from structure point of view wouldn't be great to have all endpoints acting as STS exist in single service? also that might save some roundtrips.

In all cases, I won't take more of your time, the message is delivered. and thanks again for all what you did in IT security domain.

[leastprivilege]

the message is delivered

Since you are asking for that feature, what would be your use case?

[jawadatgithub]

I came across UMA, while I was trying to find secure and standard way to embed/integrate users permissions for enterprise SPA.

As we know, OIDC & OAuth2 methodology of securing APIs using roles scope, resource scopes and defining few access claims for user, is primitive and limited, in which it only define one/single level of access control, in addition to the fact that OIDC & OAuth2 ignored common and critical essence of user experience where user permissions can be used to hide all UI sections that the user can't interact with.

Because of that limitation, most people be forced to use what's being provided by OIDC and OAuth2 even it hurt user experience by:

• Deciding to ignore UI dynamic layout based on user permissions. in most cases they limited to use the userid to hide what owned by the user. ex:, if user x created asset a, only he/she can delete or update asset a.
• Abusing access-token size in case number of APIs relatively large or customer require multi access control for each API. ex:, if SPA communicate with 20 APIs (20 or 50 is normal thing in micro-services architecture), and for each API action (get, post, put, delete) its required to have access control (permit, forbid). how we can fit all that in access-token?

Also security experts defended OIDC & OAuth2 by saying that user access is implementation details that can't be standardized as it depend on company vision and project requirements. (I agree but that's not solution, as UMA introduced 2 endpoints to manage user permissions without limitation or drawbacks, every OIDC & OAuth2 provider should implement it as resolution for above limitations).

Until UMA get embedded or integrated with idsrv3, I have 2 options:

• define claim for user perms where the value is just a code that need to be translated in lookup table:

ex:
{ "Id": "new guid", "Subject": "user-guid", "ClaimType": "perms", "ClaimValue": "03 31 32 07" }

in lookup table: 03 could mean export reports.etc.,

• OR: develop User permissions API that require idsrv3 valid access-token, then based on user role embedded in the token (if any) the API will return user permission set as defined in external data store/DB. but that's somehow part of what UMA already defined. so why reinventing the wheel?

I hope the use case interest you.

[leastprivilege]

a) I still don't get why UMA must be part of identityserver? it seems to me like a standalone "permission service" where the endpoints are secured by an access token from an authorization server.

b) my understanding was that UMA - UM being User-Managed - is more for consumer / self-service style applications - but you want to target an "enterprise SPA".

So my question still stands - an UMA server sounds to me like something separate to the authorization server - deliberately. Why do you think it must be embedded.

Or IOW - if you would write a UMA server - what would we need to change to be able to integrate with yo (or rather vice versa)?

[leastprivilege]

and btw - I am not trying to criticize you - I am just trying to understand more about UMA and its use cases.

[tienw]

I am trying to understand what is UMA and found this online

https://docs.kantarainitiative.org/uma/rec-uma-core.html

User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control ......

[jawadatgithub]

I didn't feel being criticized, but part of me regret the fact of highlighting UMA because I was not planing to invest time digging into details (even it sound selfish). Nonetheless I can't ignore or run away from something I started.

OK, I did my homework (took 4 hours including this post drafting):

1. Your understanding of UMA as user-managed (aka user in control) is totally valid and its the core of UMA (ex., IoT), but one of the approved use cases, used UMA as enterprise in control (ex., swap user (RO) with enterprise admin employee (RO)) ref: http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Access+Management+2.0+for+the+Enterprise
2. This link, shows all use cases in tabulated form that shows each case summary (designed for busy people to take a quick look) https://kantarainitiative.org/confluence/display/uma/Case+Studies
3. Getting to the main point (why UMA should be embedded or what customizations required in idsrv3):

• Authorization Server Configuration Data (3.5 pages):
  https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13#section-1.4 OR https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.1.4
• After studying the section, idsrv3 token endpoint must issue 2 new tokens:
  PAT or AAT. A requested scope of uma_protection results in a PAT. A requested scope of uma_authorization results in an AAT. and in order for that to happen, it seems embedding UMA is mandatory, do you agree?
• also I checked two OpenSource UMA provider, and both embedded it in single STS along with OIDC & OAuth2.

[leastprivilege]

Cool - thanks for the write-up. We are actively thinking about ways to improve the fine grained authorization story - but never came across something compelling. Nor did we have the time.

I will leave this open.

[thabart]

I don't think it's good idea to support UMA on identity server.
Indeed to have a decoupled architecture and don't mix the responsibilities between solutions.
It's better to create an another solution that implements UMA.
I already spend some times on it, take the time to analyse the technical architecture & I identified 2 components :

• Authorization server (Identity Server)
  • Introspection endpoint (needed to check the AAT & PAT)
  • Registration endpoint
  • Authorization endpoint
• Uma project
  • Resource set endpoint
  • Rpt endpoint
  • Rpt introspection endpoint
  • Permission endpoint

[BruceHunter]

I personally do not believe that Identity Server should be doing Registration. That should be up to separate projects / clients; to go back to your decoupled architecture comment.

[thabart]

The registration endpoint is coming from the OpenId's RFC : http://openid.net/specs/openid-connect-registration-1_0.html. It needs to be implemented by the Authorization Server to pass the latest OpenId certification "OP dynamic" : http://openid.net/certification/

[jawadatgithub]

1. If I still remember OP dynamic is not mandatory for UMA.
2. Also I remember that @leastprivilege mentioned somewhere he won't implement OP dynamic (maybe I am wrong or things changed), but based on my memory I wouldn't introduce UMA if registration endpoint was mandatory.
3. @thabart if token/introspection endpoint need to issue AAT & PAT tokens, then what sort of decoupling can be used without complicating the code?

[thabart]

1. There's nothing to change in identity server to support AAT & PAT.
   Two new clients need to be added by the developer, the first one contains the scope "uma_protection" & the second "uma_authorization".
   1 & 2 : Indeed it's not mandatory to implement OP dynamic for UMA, but you're skipping an important feature "self-client registration". Depending on your requirements maybe you don't need it ;)

[BruceHunter]

I take back what I said about the Registration endpoint.

I've just glanced over that spec for registration. What if you have a Client "Admin" area where you create Registration accounts and it's not "Allow Anonymous"; how will that work? I am assuming there will be no issues?

[thabart]

if i've correctly understood your question, you've a client (a website) that wants to restrict the access to the "admin" page based on the resource owner's roles, is-it correct ?
It it's the case, then your client can register himself against the registration endpoint & asks to access to the "openid & role" scopes.

[BruceHunter]

Yeah, so it's controlled primarily through Client configurations via Scopes + Roles. I figured that. The page acts like the login page.

[thabart]

The UMA specification has been implemented on my personnal project (ASP.NET CORE). The source code can be found here : "https://github.com/thabart/SimpleIdentityServer/tree/master/SimpleIdentityServer/src/SimpleIdServer.Uma.*". Unfortunately there's no documentation, but it can easily be linked to IdentityServer or mine by updating the AppSettings.json file.

There's also a UI to help developers to protect their resources : http://g.recordit.co/Gsqqu6uq58.gif
If you want more information about the project, you can always ask some questions.

[brockallen]

We can probably close this one here, since IS3 is not longer in active development. // @leastprivilege