[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