Planing to use FusionAuth entity based RBAC, but it is not clear could it cover full CRUD.

mou

Hi, community. I would like to refer to your experience.

We're currently bootstrapping our application and have found FusionAuth to be a great fit. Our model comprises three key resources: root, team, project, and resource, which are organized hierarchically:

Root (a singular object for defining global roles and permissions)
- Teams
  - Projects
    - Resources

To expedite our product's bootstrap process, we're considering fully integrating this hierarchy within FusionAuth. This integration would serve not only our RBAC (Role-Based Access Control) requirements but also simplify complexity in the early stages. However, this approach necessitates full CRUD (Create, Read, Update, Delete) capabilities for these entities.

Here's where we encounter our challenge: Although I've gone through the FusionAuth API documentation and understand the basic CRUD operations, there seems to be a gap. Specifically, we need a way to execute queries like "List all projects where a user has role X or grant Y," without maintaining a separate database for all entities. The search API call in FusionAuth appears limited and doesn't seem to meet this need.

This leads to our main question: Is it necessary to store all entities in an additional database to list them as needed, or can FusionAuth manage this internally?

Alex Patterson

Roles are associated with applications and users, whereas grants are associated with users and entities.

To find all users with role X or grant Y, you'd need to make two different search calls like this:

By Entity

GET/api/entity/grant/search?entityId={uuid}

By User

GET/api/entity/grant/search?userId={uuid}

You don't need to maintain a separate database.

Here's an example of a grant search for a user: https://fusionauth.io/docs/apis/entities/grants#search-for-grants

If you search for the string Example JSON in the page you will also see the link to Entity APIs

mou

@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.