Skip to content

OpenFGA setup

Jump to bottom
Barco edited this page Jul 23, 2024 · 6 revisions

OpenFGA setup and seeding

Below is a set of steps to get anyone up and running with a working OpenFGA model containing a meaningful dataset

Requirements

  • 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

Store and Model creation

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"
  }
}
    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"
}

Seeding

  • 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

UI Authorization (Browser users use case)

UI authentication will be cookie based and will follow what has been described in the spec ID036.

For authorization, user identifier is going to be the email, to allow access to resources a correspondent OpenFGA tuple will look like

- object: privileged:superuser
  user: user:<email>
  relation: admin

REST API Authorization for service accounts (CLI use case)

API authorization has been moved to use full OIDC, this means that to use the REST api now you need to have a valid OAuth2 client enabled to perform the Client Credentials Flow to retrieve an Access Token.

Each API call will need to pass the Authorization: Bearer <token> header with the Access Token service users (or better clients using this method of authentication) are identified by their subject in the access token which will match the client-id of the generated client

- object: privileged:superuser
  user: user:<oauth2-client-id>
  relation: admin
Clone this wiki locally