[Openid-specs-authzen] Authorization Use Case
kelly at sauke.net
kelly at sauke.net
Thu Jun 27 21:09:20 UTC 2024
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
2) SPA / UI MAY "pre-authorize" (via the PDP) for UX purposes only (this
is not a security control)
3) Microservice should not leak internal implementation details nor
require consumers to have knowledge of implementation details
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.
Thanks,
-Kelly
More information about the Openid-specs-authzen
mailing list