[OpenID] Beginner's Question: Per-Function-Access-Rights

Wed May 18 13:24:03 UTC 2022

I'll jump in here and suggest that User Managed Access (UMA) might be an
acceptable fit for you.  The use case for UMA is more tailored to shifting
the power of authorization to users, but the toolset offered in the spec
might be something usable for your case.  So, it's not exactly what you
need.  But to my knowledge, it's the only open specification that extends
OAuth2 and OIDC with a goal of implementing access control.

https://wso2.com/library/article/2018/12/a-quick-guide-to-user-managed-access-2-0/

https://kantarainitiative.org/confluence/display/uma/UMA+FAQ

https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html

On Wed, May 18, 2022 at 6:24 AM [Quipsy] Markus Karg <karg at quipsy.de> wrote:

> Joseph,
>
>
>
> thanks a lot for your kind answer. We really appreciate all ideas!
>
>
>
> Actually we need to say that we are an ISV, so we are NOT in the position
> of selecting an IDP vendor. What we actually strive for is understanding
> the general OpenID / OAuth2 pattern, how we can integrate into ANY existing
> company infra structure for SSO. Our customers all over the world already
> have chosen their IDPs to implement SSO, so there is NO SINGLE IDP and no
> choice BY US. They expect from us that our highly complex
> per-function-grants still work well with their particular IDP OR that the
> IDP only does SSO but not authorization. In particular, they do NOT enforce
> to manage access rights within their IDP; i. e. it is OK for them to just
> create ID Token with their particular IDP, forward the ID Token to us, and
> let us do authorization on our own in a custom way (if no better solution
> possible).
>
>
>
> Moreover, as we are dedicated open source committers, we strive for a free
> solution. So paying someone for answers on the OpenID / OAuth2 standards is
> out of scope for us. We do not have custom questions or product specific
> question, we only ask about the standards themselves. So we like to abstain
> from project-specific consulting / vendor-specific solutions.
>
>
>
> Hence our questions more clearly actually are:
>
>    - Is there something in OpenID / OAuth2 that fulfils
>    per-function-grants, or do these standards only define RBAC?
>    - Does OpenID / OAuth2 allow the separation of the authorization
>    endpoint vendor from the token endpoint vendor? If yes, we would implement
>    our own token endpoint producing our custom authorization tokens in
>    exchange for a standardized ID Token obtained from the IDP.
>    - Do OpenID / OAuth2 off-the-shelf products / services allow to create
>    custom tokens? The question is not just if there is SOME product able to do
>    that, but if that is a standardized functionality of OpenID / OAuth2.
>
> Thanks!
>
> -Markus
>
>
>
> *Von:* Joseph Heenan <joseph at authlete.com>
> *Gesendet:* Mittwoch, 18. Mai 2022 10:26
> *An:* [Quipsy] Markus Karg <karg at quipsy.de>
> *Cc:* general at lists.openid.net
> *Betreff:* Re: [OpenID] Beginner's Question: Per-Function-Access-Rights
>
>
>
> Hi Markus
>
>
>
> The question you ask is perhaps deceptively simple. I think probably most
> commercial iDPs should have a solution that fits your needs, but they won’t
> necessarily all have the same solution, depending on the exact performance
> / security / user experience needs. It’s probably a little hard to give
> much in the way of concrete advice without a lot more info about your goals.
>
>
>
> The general starting position is normally that the OpenID Connect id_token
> contains the details of the authentication event, and the OAuth2 access
> token (generally issued as part of the same flow) represents the
> authorisation(s). (For various reasons this distinction isn’t always that
> clear.) The ID Token is generally expected to be consumed by the client,
> whereas the access token is expected to be consumed by the resource
> server(s) / API endpoints.
>
>
>
> The simple solution is likely that your authorization server directly
> issues an access token that is the ‘custom authorization token containing
> the roles AND the per-function-grants’ (this could be a JWT/similar access
> token that directly contains all the details, or an opaque token that can
> be introspected to see what the user has access to - the latter is perhaps
> along the lines you describe in ‘C’, most API gateways should support token
> introspection as defined in https://datatracker.ietf.org/doc/html/rfc7662
> ).
>
>
>
> There’s generally a lot to consider when picking your solution here,
> particularly as you’re likely to be stuck with whatever solution you
> implement for a long time - it’d probably be worthwhile to engage with the
> pre-sales process at a particular vendor, who should be able to give you
> guidance on the best way to address your use cases with their solution, or
> to engage with a vendor neutral consultant that could help you select the
> best vendor - there’s a few on the OpenID Foundation members list,
> https://openid.net/foundation/sponsoring-members/
>
>
>
> Cheers
>
>
>
> Joseph
>
>
>
>
>
> I am new to OpenID and OAuth2 and read several tutorials and references
> but there is one problem left open I hope you can help with.
>
>
>
> Our existing application does RBAC with the addition of a complex system
> of functionality-grained access rights. This means, an authentication token
> must contain not only roles a user has, but also additional functionalities
> he is allowed to do. Example: A user that is in the role „Editor“ might
> have (or might not have) the additional right to execute a special function
> X. As our application is huge, besides lots of roles there are literally
> hundred of optional functionalities he could be granted or not. To our
> knowledge, this is not covered by any of the existing authentication
> services / products.
>
>
>
> We did not find a solution for this in „pure“ OpenID Connect / OAuth2, so
> currently we discuss the following attempts:
>
>
>
>    1. Let OpenID Connect do ONLY Authentication but not Authorization.
>    This means, our client sends the obtained ID Token to our existing custom
>    authorization service in exchange for a custom authorization token
>    containing the roles AND the per-function-grants.
>
>
>
>    1. Let OpenID Connect do BOTH Authentication and Authorization, but
>    wrap each single function-based-grant as a role. In the end, this means a
>    token needs to contain literally hundred of roles in turn, which makes it
>    unmanageable in literally all OpenID Connect services / products we
>    evaluaged so far.
>
>
>
>    1. Maybe there is a standardized flow that allows an authorization
>    service dynamically lookup the function-based-grant from our custom
>    authorization service?
>
>
>
> Maybe there are other solutions to that problem, but we could not image
> them.
>
>
>
> Any comments welcome (besides: do not use per-function-access-rights as
> this is axiomatic for our product)! 😊
>
>
>
> -Markus
>
>
>
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20220518/22879791/attachment-0001.html>