[Openid-specs-authzen] Authorization Use Case
Omri Gazitt
omri at aserto.com
Fri Jun 28 21:00:02 UTC 2024
Good discussion!
The way we've modeled what we call "UI hints" through an OPA policy is to
define different decisions: allowed is used for enforcement by the back-end
API, and visible / enabled are used to provide hints to the UI on whether
the user has a permission on a resource.
In OPA at least, it's pretty trivial to combine these into a single policy.
For example, for an endpoint that protects the DELETE /api/users/:id route,
we could have this policy:
package peoplefinder.DELETE.api.users.__id
default allowed = false
default visible = false
default enabled = false
allowed {
props = input.user.properties
props.department == "Operations"
props.title == "IT Manager"
}
visible {
props = input.user.properties
props.department == "Operations"
}
enabled {
allowed
}
This policy is an ABAC style policy that allows an operation if the user is
in the Operations department and is an IT Manager, and has UI hints for
whether the "delete" button is visible / enabled.
Another element of this is filtering - i.e. showing a user only the
resources that they can access. This should be achievable using the
forthcoming AuthZEN search APIs, which we've chosen to defer until after
the first implementer's draft.
Thanks,
Omri.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240628/f53bf44b/attachment.html>
More information about the Openid-specs-authzen
mailing list