ea2aa27f15
* rename to overview * wip * wip * wip * wip * wip * wip * examples * ts example * wip with grafana * add grafana tutorial * screenshots and grafana * figure out oauth proxy * authz oauth proxy * move img * merge from master * reviewed documentation * reviewed documentation * wip * wip * wip * wip * wip * wip * examples * ts example * wip with grafana * screenshots and grafana * figure out oauth proxy * authz oauth proxy * move img * merge from master * cleaned up name for management roles * corrected small typo in code * Intro for orgs, spelling, ref to mgmt roles * removed inline comments * Update 00-quick-start.en.md * Update 02-organisations.en.md * Update site/docs/administrate/03-projects.en.md Co-authored-by: Florian Forster <florian@caos.ch> * Update 03-projects.en.md * Update 04-clients.en.md * Update site/docs/administrate/07-policies.en.md Co-authored-by: Florian Forster <florian@caos.ch> * Update 09-authorizations.en.md Co-authored-by: Florian Forster <florian@caos.ch>
4.8 KiB
| title |
|---|
| Projects |
What are projects
The idea of projects is to have a vessel for all components who are closely related to each other. In ZITADEL all clients located in the same project share their roles, grants and authorizations. From an access management perspective you manage who has what role in the project and your application consumes this information. A project belongs to exactly one organisation.
The attribute project role assertion defines, if the roles should be integrated in the tokens without sending corresponding scope (urn:zitadel:iam:org:project:role:{rolename})
With the project role check you can define, if a user should have a requested role to be able to logon.
Clients
These are your applications who initiate the authorization flow (see What are clients).
Roles
Roles (or Project Roles) are a means of managing users access rights for a certain project. These roles are opaque for ZITADEL and have no weight in relation to each other.
As example, if user has two roles, admin and user in a certain project, the information will be treated additive. There is no meaning or hierarchy implied by these roles.
Grants
With ZITADEL it is possible to give third parties (other organisations) the possibility to manage certain roles on their own. As a service provider, you will find this feature useful, as it allows you to establish a self-service culture for your business customers.
The owner of a project can grant (some would say "delegate") certain roles or all roles to another organisation. The target organization can then independently manage the assignment of their users to the role within the granted project.
Authorizations
TODO, Link to authorizations
Project vs. granted Project
A project belongs to your organisation. You can grant certain roles to another organization. A granted project, on the other hand, belongs to a third party, granting you some rights to manage certain roles of their project.
To make it more easier to differentiate ZITADEL Console displays these both as separate menu in the project section.
Manage a project
Create a project
To create your project go to https://console.zitadel.ch/projects
Create a new project with a name which explains what's the intended use of this project.
RBAC Settings
- Authorisation Check option (Check if the user at least has one role granted)
- Enable Project_Role Assertion (if this is enabled assert project_roles, with the config of the corresponding client)
Define project specific roles
Screenshot here
Grant project to a third party
Screenshot here
Manage Project Authorisations
Screenshot here
Manage Project ZITADEL Roles
Audit project changes
Screenshot here