This message was deleted.

The use case I’m envisioning here is centralized authorization with support for workloads where sidecar containers are not available (think Lambda functions)

Hey @Ville Väänänen, one of our teammates will answer you soon 🙂

Answering my own question: since the

is_authorized

request is

POST

and requires a custom JSON body, a Caddy plugin is a better solution. Is there by any chance an authorization example using Go? I can see ones for Python and Node.

Intersting we just had a Caddy conversation in the #C059UD7D76X channel https://permit-io.slack.com/archives/C059UD7D76X/p1685589560036639 I think you can use the expanded form with a matcher that looks at the body instead of the status, so you won’t need a plugin When you say “example using Go” do you mean for sending a query to Cedar-agent?

Good point about the expanded form. However, since the cedar-agent call is based on the incoming request so loosely and since it’s POST, looks like a plugin is needed anyway.

We don’t have a Golang example, we can easily create one if you’d like

That’d be nice 👍 . Maybe by adding a Golang version here: https://github.com/permitio/opal-cedar/tree/main/applications

Yes, you would need to write a data fetcher that will fetch the data from your DynamoDB in order to store it inside the cedar-agent. It is required because the cedar-agent uses the injected data for the authorization enforcement ( same logic goes for the policy ).

Could I also use DDB for broadcasting?

Currently the only supported broadcasters are: Postgres LISTEN/NOTIFY Redis Kafka

Are there any important differences when it comes to the broadcasting functionality if I can choose any?

No, they are all abstractes in OPAL into just a pub/sub channel. It's simply a matter of preference or what you already have in place