RBAC rules
Dgraph support Role Based Access Control (RBAC) on GraphQL API operations: you can specify who can invoke query, add, update and delete operations on each type of your GraphQL schema based on JWT claims, using the @auth
directive.
To implement Role Based Access Control on GraphQL API operations :
- Ensure your have configured the GraphQL schema to Handle JWT tokens using
# Dgraph.Authorization
This step is important to be able to use the JWT claims - Annotate the Types in the GraphQL schema with the
@auth
directive and specify conditions to be met forquery
,add
,update
ordelete
operations. - Deploy the GraphQL schema either with a schema update or via the Cloud console’s Schema page.
The generic format of RBAC rule is as follow
type User @auth(
query: { rule: "{$<claim>: { eq: \"<value>\" } }" },
add: { rule: "{$<claim>: { in: [\"<value1>\",...] } }" },
update: ...
delete: ...
)
Where <claim>
is a JWT claim from the JWT token payload.
You can use eq
or in
function to test the value of any claim.
For example the following schema has a @auth directive specifying that a delete operation on a User object can only be done in the connected user has a ‘ROLE’ claim in the JWT token with the value “ADMIN” :
type User @auth(
delete: { rule: "{$ROLE: { eq: \"ADMIN\" } }"}
) {
username: String!
@id todos: [Todo]
}
rules combination
Rules can be combined with the logical connectives and
, or
and not
.
A permission can be a mixture of graph traversals and role based rules.
In the todo app, you can express, for example, that you can delete a Todo
if you are the author, or are the site admin.
type Todo @auth(
delete: { or: [
{ rule: "query ($USER: String!) { ... }" }, # you are the author graph query
{ rule: "{$ROLE: { eq: \"ADMIN\" } }" }
]}
)
claims
Rules may use claims from the namespace specified by the # Dgraph.Authorization or claims present at the root level of the JWT payload.
For example, given the following JWT payload
{
"https://xyz.io/jwt/claims": [
"ROLE": "ADMIN"
],
"USERROLE": "user1",
"email": "random@example.com"
}
The authorization rules can use $ROLE
(if https://xyz.io/jwt/claims
is declared as the namespace to use ) and also $USERROLE
or $email
.
In cases where the same claim is present in the namespace and at the root level, the claim value in the namespace takes precedence.
@auth
on Interfaces
The rules provided inside the @auth
directive on an interface will be applied as an AND
rule to those on the implementing types.
A type inherits the @auth
rules of all the implemented interfaces. The final authorization rule is an AND
of the type’s @auth
rule and of all the implemented interfaces.