ef3b7482cd
* chore: cleanup old docs folder * remove docs path trigger * wip docs structure * chore: ignore site changes in ci * add manuals route * new structure * structure * Use correct title * remove trigger for code scan for static site generator * change names * add lorem ipsum to test styling * use h3 to deeplink * add site to dependabot * lint readme.md * remove not needed file * ignore site on pull request code scan * add initial contrib * Minor correction * Added section Developer & Integration * Changed link list layout, added labels, added translations * Added missing <li> tags * Added correct link to section Developer & Integration * Fixing list style * Overhauling description texts and translations * outline * teaser go * outline * wip * rework * wip * wip * wip * hop * wip * first draft for "administrate" done * init outline * fix deploy step * lint * commit wip * commit wip * md lint * Link * fix: path to edit (#711) * wip * wip * wip * what are... * use only features * wip docs * Update 00-user.en.md * project * uppercase en * wip * wip * wip * policies rework * improve text * correct typo * update readme * correct styling * add link to docs guides * make the linter happy * rename * wip * move api to own file * correct links and lint * wip roles and integration * add pkce * reduce padding and margin * wip scope and claims * wip claim & scopes * make the linter happy * insert links where possible * wip * wip roles & providers * Update README.md * Update 00-user.en.md * minor text improvements * use master branch to deploy * use proper ci file * Apply suggestions from code review Co-authored-by: Fabi <38692350+fgerschwiler@users.noreply.github.com> Co-authored-by: Matthias M. Schneider <mati@matimax.info> Co-authored-by: Max Peintner <max@caos.ch> Co-authored-by: Fabi <38692350+fgerschwiler@users.noreply.github.com>
2.4 KiB
| title |
|---|
| Roles |
What are Roles
With roles ZITADEL lets projects define there role based access controle.
Roles can be consumed by the clients which exist witing a specific project.
For more information about how roles can be consumed have a look the the protocol specific information.
Manage Roles
Each role consist of three fields.
| Field | Description | Example |
|---|---|---|
| Key | This is the Roles actual name which can be used to verify the users roles. | User |
| Display Name | A descriptive text for the purpose of the Role | User is the default role provided to each person |
| Group | The group field allows to group certain roles who belong in the same context | User and Admin in the group default |
Grantig Roles
To give someone (or somewhat) access to a projects resources and services ZITADEL provides to processes. Roles can be either granted to users org to organisations.
Grant Roles to Organisations
The possibility to grant roles to an organisation is intented as "delegation" so that a org can on their own grant access to users.
For example a service provider could grant the roles user, and manager to an org as soon as they purchases his service. This can be automated by utilising a service user in the service providers business process.
Screenshot here
Grant Roles to Users
By granting roles to users, be it humanes or machines, this user recieves the authorization to access resources from a service.
Screenshot here