[Openid-specs-authzen] Authorization Use Case

Alex Babeanu alex at 3edges.com
Fri Jun 28 22:24:00 UTC 2024


Hi Kelly...

Thanks for contributing ! Adding to What David and Omri said:

- What you call "pre-authorization" is Coarse-Grained access to the UI: the
UI/UX needs to decide what to display based on some condition(s), such as
group/role membership.* A Business user or App admin *can write these
access policies.

- Your Micro-Service policies are more fine-grained, and would probably be
written/maintained by the *developers* or people in charge of those
micro-services.

- Finally, in order for your UI to work, there needs to be a mapping
somewhere between your UX coarse-grained rules and those finer grained
policies. The same personas as above could probably create this.

Some platforms allow these various types of Personas to collaborate, but
anyway, in the end, the AuthZen call made by your WebApp would be handled
by the PDP, as a"blackbox". The PDP would have to "know" how to map the UI
stuff to the backend stuff. So it all boils down to ensuring that different
groups can collaborate on these policies (some AuthZ platforms enable this
-- wink,wink).

Hope it helps...

./\.


On Fri, Jun 28, 2024 at 10:44 AM David Brossard via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> Hi Kelly,
>
> Thanks for your note. Please see my comments below
>
> On Thu, Jun 27, 2024 at 2:18 PM Kelly Sauke via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> Everyone-
>>
>> The conversation about the "search" use case for UIs got me thinking
>> about a particular use case that I thought I'd drop here for discussion.
>> Before I describe the use case, here are some design rules that we've
>> set internally that apply directly to this conversation.
>>
>> 1) SPA / UIs do not make authorization decisions.  All AuthZ final
>> decision is the responsibility of the backend microservice
>>
> *Agreed. Anything that happens in any kind of front-end is not security.
> It's merely usability.  This ties nicely back to OWASP's Proactive Controls
> C5 and C7:*
>
>    -
> *https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs
>    <https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs>
>    *
>    -
> *https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls
>    <https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls>
>    *
>
> 2) SPA / UI MAY "pre-authorize" (via the PDP) for UX purposes only (this
>> is not a security control)
>>
> *Agreed. This is usability. I do think it's important and helps deliver
> better UX and deflect invalid use cases.*
>
>> 3) Microservice should not leak internal implementation details nor
>> require consumers to have knowledge of implementation details
>>
> *Agreed.*
>
>>
>> While we do want Enterprise level authorization policies that are
>> reusable, there are occasions where those enterprise policies don't map
>> nicely to UI needs for "pre-authorization". This usually comes when
>> there are microservices that are doing orchestrations across other
>> services. In the case of orchestrations, that microservice may have
>> additional domain logic it has wrapped around the Enterprise AuthZ
>> policies to make a final determination. For example: the permissions
>> needed to complete the orchestration may need read access to 2 entities,
>> update access to a 3rd and create access to a 4th. This logic should not
>> be leaked nor be required to be implemented by the UI to "pre-authorize"
>> whether a user can take some the orchestrated action. When using
>> standard patterns with those orchestration use cases, we break either
>> rule 1 or rule 3.  This also isn’t really an enterprise policy, in my
>> opinion, as it is still a “pre-authorization” even within the
>> orchestration microservice. The downstream services will have the final
>> say in the authorization of the various actions its taking.
>>
>> I’ve been tossing around the idea of an interrogation endpoint exposed
>> by the specific microservices for “pre-authorization” purposes.  I.E. UI
>> user experience optimizations.  It would be great if there could be a
>> standard for what that would look like.  I’ve thought about just
>> exposing the upcoming AuthZen contract on /access/v1/evaluation or
>> similar endpoint within the orchestration microservice.  It would answer
>> based on its internal logic and responses from the enterprise PDP.  I’ve
>> also thought about using HTTP OPTIONS on the actual endpoint route to
>> answer the question, but that’s may be a little more of a departure than
>> just exposing an /evaluation endpoint.  I’ve also thought about adding
>> that as an enterprise policy, but that feels redundant to me and is
>> really specific to that UI Optimization.  Or creating a specific UI
>> policy, but again that would be duplication of what is happening in the
>> microservice.  Or perhaps I’m just being overly pedantic in thinking
>> this use case should be treated differently, IDK.
>>
>> In the end, I just wanted to throw this out for discussion.
>>
>
> *I think the AuthZEN endpoints should be able to address that and maybe we
> need to define usage patterns to guide implementers down the right path.
> The way I've seen it done in the past is either:*
>
>    1. *Have a business policy that focuses on the actual access (users
>    printing documents) and a policy that's dedicated to the UI elements (e.g.
>    A user with the role customer can view the "print button" feature if they
>    have enough credits, or*
>    2. *Have the business policy only - this avoid polluting your policies
>    with UI-specific concerns.*
>
> *In the first case, we can use the evaluation endpoint of AuthZEN to get a
> true/false decision back. In the latter case, you'd have to use the Search
> API and essentially ask the "PDP": tell me which features Alice has access
> to. The PDP would reply with "search, edit..."*
>
> *The latter is cleaner of course but there's more burden (at least with
> existing XACML-based APIs) on the developer and so I've seen a lot of
> customers go down the first path.*
>
> *I hope this helps,*
> *David*
>
>>
>>
>> Thanks,
>> -Kelly
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>
>
> --
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: IC3 Prevention Tips
> <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
> Prenez vos précautions sur Internet:
> http://www.securite-informatique.gouv.fr/gp_rubrique34.html
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>


-- 
[image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
Their phone number is +1 604 728 8130.]
<https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments 
hereto, is for the sole use of the intended recipient(s) and may contain 
confidential and/or proprietary information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240628/4e57c38d/attachment-0001.html>


More information about the Openid-specs-authzen mailing list