hasura / hasura/graphql-engine
Add support for Entitlement-based Authorization
- Dominant language
- TypeScript
- Stars
- 32.1k
- Forks
- 3k
- PR merge metrics
- PR metrics pending
Description
### Component
c/v3-engine
### Is your proposal related to a problem?
No
### Describe the solution you'd like
Entitlement-based authorization would allow for more granular access control based on specific attributes of the data being accessed. Currently, if Hasura receives a request for an attribute the requestor does have access to, the query will not execute and an error is returned. Entitlements would allow for this query to execute, but only return the data that the requestor has access to. Attributes the requestor does not have access to will be blank (empty string or null, etc.) For example, if I have a User object with this shape:
```graphql
Employee: {
name: "john smith",
email: "jsmith@example.com",
salary: 100000,
location: "Chicago, IL",
lastLogin: 2024-06-24T18:01:46.072Z
}
```
With this Entitlements configuration:
`default` entitlement has access to `name`, `email` properties
`salary`entitlement has access to everything `default` has access to, plus `salary`
`location` entitlement has access to everything `default` has access to, plus `location`
As the requestor, if I have the `default` entitlement and make a request for the full `Employee` object, I will see the following:
```graphql
data: {
name: "john smith",
email: "jsmith@example.com",
salary: null,
location: "",
lastLogin: null
}
```
If I have the `salary` and `location` entitlements, I will see:
```graphql
Employee: {
name: "john smith",
email: "jsmith@example.com",
salary: 100000,
location: "Chicago, IL",
lastLogin: null
}
```
if I have an `admin` entitlement, I have access to all attributes
### Describe alternatives you've considered
None. Current Authorization rules do no provide this.
Contributor guide
Research direction
Start by reviewing the c/v3-engine component and its current Authorization rules. Determine how entitlement-based field access should interact with the existing authorization behavior and the null or empty values described in the examples. Done means authorized fields remain visible while unauthorized fields are returned without preventing the query from executing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql
- Domain
- api, authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100