<div dir="ltr"><div>Hi Kelly,</div><div><br></div><div>Thanks for your note. Please see my comments below</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2024 at 2:18 PM Kelly Sauke via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net">openid-specs-authzen@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Everyone-<br>
<br>
The conversation about the "search" use case for UIs got me thinking <br>
about a particular use case that I thought I'd drop here for discussion. <br>
Before I describe the use case, here are some design rules that we've <br>
set internally that apply directly to this conversation.<br>
<br>
1) SPA / UIs do not make authorization decisions.  All AuthZ final <br>
decision is the responsibility of the backend microservice<br></blockquote><div><i><font color="#cc0000">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:</font></i></div><div><ul><li><i><font color="#cc0000"><a href="https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs">https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs</a><br></font></i></li><li><i><font color="#cc0000"><a href="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</a><br></font></i></li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) SPA / UI MAY "pre-authorize" (via the PDP) for UX purposes only (this <br>
is not a security control)<br></blockquote><div><i><font color="#cc0000">Agreed. This is usability. I do think it's important and helps deliver better UX and deflect invalid use cases.</font></i> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3) Microservice should not leak internal implementation details nor <br>
require consumers to have knowledge of implementation details<br></blockquote><div><i><font color="#cc0000">Agreed.</font></i> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
While we do want Enterprise level authorization policies that are <br>
reusable, there are occasions where those enterprise policies don't map <br>
nicely to UI needs for "pre-authorization". This usually comes when <br>
there are microservices that are doing orchestrations across other <br>
services. In the case of orchestrations, that microservice may have <br>
additional domain logic it has wrapped around the Enterprise AuthZ <br>
policies to make a final determination. For example: the permissions <br>
needed to complete the orchestration may need read access to 2 entities, <br>
update access to a 3rd and create access to a 4th. This logic should not <br>
be leaked nor be required to be implemented by the UI to "pre-authorize" <br>
whether a user can take some the orchestrated action. When using <br>
standard patterns with those orchestration use cases, we break either <br>
rule 1 or rule 3.  This also isn’t really an enterprise policy, in my <br>
opinion, as it is still a “pre-authorization” even within the <br>
orchestration microservice. The downstream services will have the final <br>
say in the authorization of the various actions its taking.<br>
<br>
I’ve been tossing around the idea of an interrogation endpoint exposed <br>
by the specific microservices for “pre-authorization” purposes.  I.E. UI <br>
user experience optimizations.  It would be great if there could be a <br>
standard for what that would look like.  I’ve thought about just <br>
exposing the upcoming AuthZen contract on /access/v1/evaluation or <br>
similar endpoint within the orchestration microservice.  It would answer <br>
based on its internal logic and responses from the enterprise PDP.  I’ve <br>
also thought about using HTTP OPTIONS on the actual endpoint route to <br>
answer the question, but that’s may be a little more of a departure than <br>
just exposing an /evaluation endpoint.  I’ve also thought about adding <br>
that as an enterprise policy, but that feels redundant to me and is <br>
really specific to that UI Optimization.  Or creating a specific UI <br>
policy, but again that would be duplication of what is happening in the <br>
microservice.  Or perhaps I’m just being overly pedantic in thinking <br>
this use case should be treated differently, IDK.<br>
<br>
In the end, I just wanted to throw this out for discussion.<br></blockquote><div><br></div><div><i><font color="#cc0000">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:</font></i></div><div><ol><li><font color="#cc0000"><i>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</i></font></li><li><i style="color:rgb(204,0,0)">Have the business policy only - this avoid polluting your policies with UI-specific concerns.</i></li></ol><div><font color="#cc0000"><i>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..."</i></font></div></div><div><font color="#cc0000"><i><br></i></font></div><div><font color="#cc0000"><i>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></font></div><div><font color="#cc0000"><i><br></i></font></div><div><font color="#cc0000"><i>I hope this helps,</i></font></div><div><font color="#cc0000"><i>David</i></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
-Kelly<br>
-- <br>
Openid-specs-authzen mailing list<br>
<a href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">---<br>David Brossard<br><a href="http://www.linkedin.com/in/davidbrossard" target="_blank">http://www.linkedin.com/in/davidbrossard</a><br><a href="http://twitter.com/davidjbrossard" target="_blank">http://twitter.com/davidjbrossard</a><br><a href="http://about.me/brossard" target="_blank">http://about.me/brossard</a><br>---<br>Stay safe on the Internet: <a href="https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf" target="_blank">IC3 Prevention Tips</a><br>Prenez vos précautions sur Internet: <a href="http://www.securite-informatique.gouv.fr/gp_rubrique34.html" target="_blank">http://www.securite-informatique.gouv.fr/gp_rubrique34.html</a></div></div></div>