sidebar_position | slug | description |
---|---|---|
1 |
/modeling/direct-access |
Granting a user access to an object |
import { AuthzModelSnippetViewer, CardBox, CheckRequestViewer, DocumentationNotice, Playground, ProductConcept, ProductName, ProductNameFormat, RelatedSection, WriteRequestViewer, } from '@components/Docs';
In this guide you will learn how to grant a access to an (such as a certain document) in .
Granting access with is a core part of . Without them, any will fail. You should use:
- authorization model to represent what relations are possible between the users and objects in the system
- relationship tuples to represent the facts about the relationships between users and objects in your system.
In order to understand this guide correctly you must be familiar with some and know how to develop the things that we will list below.
Assume that you have the following .
You have a called document
that can have a viewer
and/or an editor
.
You have a called
document
that can have a viewer
and/or an editor
.<AuthzModelSnippetViewer configuration={{ schema_version: '1.1', type_definitions: [ { type: 'user', }, { type: 'document', relations: { viewer: { this: {}, }, editor: { this: {}, }, }, metadata: { relations: { viewer: { directly_related_user_types: [{ type: 'user' }] }, editor: { directly_related_user_types: [{ type: 'user' }] }, }, }, }, ], }} />
In addition, you will need to know the following:
- A : a class of objects that have similar characteristics
- A : an entity in the system that can be related to an object
- A : is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system
- An : represents an entity in the system. Users' relationships to it can be define through relationship tuples and the authorization model
- A : a grouping consisting of a user, a relation and an object stored in
For our applications to understand that user x has access to document y, we need to provide that information through . Each relationship tuple has three basic parameters, a , a and an .
Let us add a to indicate that bob who is an editor
of document:meeting_notes.doc. This is represented by adding the following:
<WriteRequestViewer relationshipTuples={[ { user: 'user:bob', relation: 'editor', object: 'document:meeting_notes.doc', }, ]} />
Once that relationship tuple is added to , we can if the relationship is valid by asking the following: "is bob an editor of document:meeting_notes.doc?"
<CheckRequestViewer user={'user:bob'} relation={'editor'} object={'document:meeting_notes.doc'} allowed={true} />
If we were to check the following: "is bob a viewer of document:meeting_notes.doc?" it would return false since that relationship tuple does not exist within yet.
<CheckRequestViewer user={'user:bob'} relation={'viewer'} object={'document:meeting_notes.doc'} allowed={false} />
:::caution Note: When creating relationship tuples for make sure to use unique ids for each object and user within your application domain. We're using first names and simple ids to just illustrate an easy-to-follow example. :::
<RelatedSection description="Check the following sections for more on how to model with {ProductName}." relatedLinks={[ { title: '{ProductName} Concepts', description: 'Learn about the {ProductName} Concepts.', link: '../concepts', id: '../fga-concepts', }, { title: 'Modeling: Getting Started', description: 'Learn about how to get started with modeling.', link: './getting-started', id: './getting-started', }, { title: 'Modeling Language', description: 'Learn about {ProductName} Modeling Language.', link: '../modeling-language', id: '../modeling-language', }, ]} />