[Openid-specs-authzen] Authorization Use Case
David Brossard
david.brossard at gmail.com
Fri Jun 28 17:44:08 UTC 2024
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240628/c413266c/attachment-0001.html>
More information about the Openid-specs-authzen
mailing list