search

dapr / proposals

Proposals for new features in Dapr
Apache License 2.0
15 stars 33 forks source link

Building Block: Proposal document for Gatekeeper Building Block #14

Open XavierGeerinck opened 1 year ago

XavierGeerinck commented 1 year ago

This proposal documents introduces the "Gatekeeper" building block which helps developers to implement "Authorization" requests for their application, assisting the developer by implementing core authorization requirements:

Am I as a user able to access resource X? Which resources am I as a user able to access? (commonly known as an "ARQ" or "Access Request Query") It works through added APIs in the Dapr runtime that work together with a state store to store the policies.

Background

While working with software, one of the most common issues that pops-up is "Authorization". After a user is authenticated, how do we know that this user has access to a specific piece in your code? For this, developers typically reside towards implementing:

The above is often considered a lengthy task, as users have to ensure that everything works as intended and test it carefully. A leak in this piece of code could have serious consequences.

Dapr runs as a sidecar architecture, typically close to the software. This software often interacts with users (Backend API) or as microservices doing an isolated piece of code.

Therefore, I would love to propose a new Building Block: "Gatekeeper", where a user can simply call it through one of the Dapr SDKs and receive a response if they are allowed to access a certain feature or not.

Vocabulary

Signed-off-by: Xavier Geerinck xavier.geerinck@gmail.com

XavierGeerinck commented 1 year ago

@dapr/maintainers-dapr thoughts?

yaron2 commented 1 year ago

@XavierGeerinck will be reviewing this soon, as back for vacation now.

XavierGeerinck commented 1 year ago

Any update @yaron2 or others?

jogobella00 commented 1 year ago

That would be great to have it in Dapr already, would it be possible to have this PR approved?

Yunzlez commented 1 year ago

+1 Also waiting for this!

XavierGeerinck commented 1 year ago

Any opinions on this? @yaron2 @artursouza

artursouza commented 1 year ago

Can it follow a spec 100%, maybe Cerbos? Similar to how we have 100% compatible cloud event in pubsub. Then, show how this can be integrated with existing 3rd party frameworks. I think the biggest value add if it can interop outside the Dapr SDKs.

XavierGeerinck commented 1 year ago

I think it would indeed allow for a 100% compatibility with their spec, the question is just what the added value of Dapr would be then. Integrating it natively in Dapr could be more seen as building block, while a cloud event is more seen as interop layer for integration

berndverst commented 1 year ago

Can someone copy the proposal text also into the description here so we can discuss this better?

Also, I'm hesitant for us to merge proposals without any identified stakeholders who are committed to driving the engineering work / implementation.

I don't fully see / understand the value of this proposal for Dapr. An interop layer makes more sense to me.

XavierGeerinck commented 1 year ago

Can someone copy the proposal text also into the description here so we can discuss this better?

Also, I'm hesitant for us to merge proposals without any identified stakeholders who are committed to driving the engineering work / implementation.

I don't fully see / understand the value of this proposal for Dapr. An interop layer makes more sense to me.

Done (partly though as it makes no sense for an entire duplication)

The ideation (and community request - see references in the proposal) are around providing an microservice angostic way of authorizing calls. The value for Dapr is immense as it is a component required by many people and would even improve Daprs current authorization mechanisms.

An interop layer could work as well, but this is where the discussion comes in in if Dapr wants this as USP (extra building block type) or not.