Entities endpoints

[marlenekoh]

Would be great to have an api endpoint for listing all entities (users, objects) within a store. This will be useful for populating dropdown lists - e.g. for a customer to request for permissions, to list all roles/documents.
In the same vein, to be able to add/remove/rename entities (which may or may not be part of relationship tuples) would be extremely helpful as well.

[aaguiarz]

Hi @marlenekoh

You should be able to use the Read endpoint for that. Let me know if that helps.

[marlenekoh]

I took a quick look, seems to be listing tuples, and that requires users/objects to be related to each other in a tuple. What I'm looking for are standalone entities

GET /stores/{store_id}/entities

# response
[
  {"type": "user", "name": "john.doe"},
  {"type": "user", "name": "jane.doe"},
  {"type": "group", "name": "contoso"}
]

and perhaps adding a filter

GET /stores/{store_id}/entities?type=group

# response
[
  {"type": "group", "name": "contoso"}
]

If these entities can be pre-populated, we can display them in a dropdown list or a form e.g. "select the groups to grant access to"

[rhamzeh]

Re:

to be able to rename entities

This is another case were we strongly recommend you do not store names or PII in OpenFGA, and rely on unique identifiers. In that case you would have the UID<>Name mapping in your DB and use that as the base for listing.

Part of that is the idea that OpenFGA is not your data store, it's your authorization data store, and if an entity does not relate to any other entity, by definition it would not affect authorization and does not need to be in OpenFGA.

We may stray away from that idea and change OpenFGA to be a more general purpose DB, but currently our design is based on:

• OpenFGA is a store for authorization data
• Objects in OpenFGA are stored using a unique ID and not a user visible or controlled name

[marlenekoh]

Got it, thanks for the clarification! We’re already using OpenFGA with a separate database to handle the UID<>Name mapping. Just wanted to confirm if this functionality might be supported natively in the future, because it would simplify things on our end.