Authorization is a must-have for every application, but most teams have to build it from scratch. The Open Policy Agent [0] is a good place to start for creating an OSS-based solution, but you still need to build a lot of stuff yourself.
The Aserto playground [1] lets you import your REST service’s openapi.json spec and automatically generates a permissions for each operation. You can assign these permissions to one or more roles (viewer, editor, admin, or create your own). Export the project to get your OPA policy for your REST service.
You can also try it out with the Petstore API [2]. Click the “Start Tour” button for a guided tour.
Technically names do not have to match, but it certainly makes it easier if you have a pattern to rely on when injecting authorization into a middleware layer.
By convention, we generate a package for every API definition in the OpenAPI spec. But the calling application can decide which package to use when authorizing an operation, so you can use a single policy for multiple endpoints.
This was meant to be a "Show" of an unauthenticated experience (i.e. no account required) for creating OPA policies, different than the thread you referenced (which linked a public beta blog post).
12 comments
[ 0.18 ms ] story [ 41.7 ms ] threadThe Aserto playground [1] lets you import your REST service’s openapi.json spec and automatically generates a permissions for each operation. You can assign these permissions to one or more roles (viewer, editor, admin, or create your own). Export the project to get your OPA policy for your REST service.
You can also try it out with the Petstore API [2]. Click the “Start Tour” button for a guided tour.
Would love feedback on how to make this better!
[0] https://openpolicyagent.org
[1] https://aserto.com/playground
[2] https://petstore3.swagger.io/api/v3/openapi.json
[0] https://www.openpolicyagent.org/docs/edge/cli/#opa-build
[1] https://github.com/opcr-io/policy