-
Notifications
You must be signed in to change notification settings - Fork 4
OpenFGA setup
Below is a set of steps to get anyone up and running with a working OpenFGA model containing a meaningful dataset
- make sure you have OpenFGA APIs accessible, in this case we will refer them as
http://127.0.0.1:8080
- have
fga
cli installed - have
jq
installed
There are 2 ways to have this setup:
-
via UI
- you can connect to the playground/ui and create a store and model
- make sure to patch the model with the content of the identity model
-
via CLI
- run the
fga
cli to create a store
shipperizer in ~/shipperizer/identity-platform-admin-ui.wiki on IAM-781 ● λ fga --api-url http://127.0.0.1:8080 store create --name admin` { "store": { "created_at":"2024-04-04T08:06:45.910906119Z", "id":"01HTM2ARCP9FFNWVC3R3ASB09E", "name":"admin", "updated_at":"2024-04-04T08:06:45.910906119Z" } }
- create the model using the identity model
shipperizer in ~/shipperizer/identity-platform-admin-ui.wiki on IAM-781 ● λ fga --api-url http://127.0.0.1:8080 model write --file ../identity-platform-admin-ui/internal/authorization/schema.openfga --store-id 01HTM2ARCP9FFNWVC3R3ASB09E { "authorization_model_id":"01HTM2CKWTB2D0Y7F05ZSQXACE" }
- run the
-
fetch MODEL_ID and STORE_ID from openfga server, the following will pick the latest model from the first store (hopefully you dont have more than 1, otherwise you will have to inspect the response and choose)
STORE_ID=$(fga --api-url http://127.0.0.1:8080 store list | jq '.stores[0].id' -r) MODEL_ID=$(fga --api-url http://127.0.0.1:8080 model list --store-id $STORE_ID | jq '.authorization_models[0].id' -r)
-
populate the model with data
fga --api-url http://127.0.0.1:8080 tuple write --model-id $MODEL_ID --store-id $STORE_ID --file openfga-tuples.yml
where
openfga-tuples.yaml
can be found below in the details# tuples - object: privileged:superuser user: user:johndoe relation: admin - object: privileged:superuser user: user:shipperizer relation: admin - object: role:administrator user: privileged:superuser relation: privileged - object: role:administrator user: user:joe relation: assignee - object: group:c-level user: user:joe relation: member - object: group:c-level user: privileged:superuser relation: privileged - object: identity:user-1 user: privileged:superuser relation: privileged - object: identity:user-2 user: privileged:superuser relation: privileged - object: scheme:identity-social user: privileged:superuser relation: privileged - object: client:github-canonical user: privileged:superuser relation: privileged - object: identity:user-1 user: user:joe relation: can_delete - object: client:github-canonical user: role:administrator#assignee relation: can_view - object: client:okta user: role:administrator#assignee relation: can_delete - object: client:github-canonical user: group:c-level#member relation: can_edit - object: client:okta user: group:c-level#member relation: can_delete - object: client:okta user: group:c-level#member relation: can_view - object: client:okta user: group:c-level#member relation: can_edit - object: role:administrator user: group:c-level#member relation: assignee - object: role:janitor user: group:c-level#member relation: assignee
Current API authorization is rudimentary at best, work will go into it in the next 6 months to make it acceptable
for the time being what is needed to be authorized is the header X-Authorization
with a base64 encoded user value
shipperizer in ~/shipperizer/identity-platform-admin-ui on IAM-726 ● λ echo -n shipperizer | base64
c2hpcHBlcml6ZXI=
PRIVILEGED_USER=c2hpcHBlcml6ZXI=
http :8000/api/v0/roles X-Authorization:$PRIVILEGED_USER
the tuples involved in this are all those matching a user
to a privileged
type
- object: privileged:superuser
user: user:shipperizer
relation: admin
setting the header will enable to get the full list of roles and groups as an admin user, otherwise anonymous
user will be used