TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2024-12-13 03:24:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: improvement to semantics (#944)

Browse Source 
* 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>
This commit is contained in:
mffap 2020-12-01 16:56:33 +01:00 committed by GitHub
parent 3deedfe863
commit ea2aa27f15
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
23 changed files with 194 additions and 101 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
site/docs/administrate/00-overview.en.md
View File

@ -40,4 +40,4 @@ title: Overview
### Concepts
With ZITADEL there are some key concepts some should be aware of before using it to secure your applications and services.
You find these definitions in the "What is..." heading of each resource.
You find these definitions in the "What is/are..." heading of each resource.

7
site/docs/administrate/01-console.en.md
View File

@ -4,7 +4,10 @@ title: Console
### What is Console
Console is the ZITADEL Graphical User Interface.
Console is the ZITADEL Graphical User Interface.
ZITADEL Console can be reached at [console.zitadel.ch](https://console.zitadel.ch/).
For dedicated ZITADEL instances this URL might be different, but in most cases should be something like `https://console.YOURDOMAIN.TLD`
#### ZITADEL Users
@ -31,7 +34,7 @@ Console is the ZITADEL Graphical User Interface.
#### ZITADEL Organisation Owners
Users (**org owners**) who manage organisations do this also with Console.
Users who manage organisations (**organisation owners**) do this also with Console.
- Organisation settings (policies, domains, idps)
- Manage users

81
site/docs/administrate/02-organisations.en.md
View File

@ -1,48 +1,67 @@
---
title: Organisations
title: Organizations
---
### What are organisations
### What are organizations
Organisations are comparable to tenants of a system or OU's (organisational units) if we speak of a directory based system.
ZITADEL is organised around the idea that multiple organisations share the same [System](administrate#What_is_meant_by_system) and that they can grant each other rights so self manage certain things.
Organizations are comparable to tenants of a system or OU's (organizational units) if we speak of a directory based system.
ZITADEL is organized around the idea that
* multiple organizations share the same [System](administrate#What_is_meant_by_system)
* these organizations can grant each other rights to self-manage certain things (eg, delegating roles)
* organizations are a vessels for [users](administrate#What_are_users) and [projects](administrate#What_are_projects)
#### Global organisation
#### Global organization
ZITADEL provides a global organisation for users who manage their accounts on their own. Think of this like the difference between a "Microsoft Live Login" vs. "AzureAD User"
or if you think of Google "Gmail" vs "Gsuite".
The global organization holds users that are not assigned to any other organization in the [System](administrate#What_is_meant_by_system). Thus ZITADEL provides a global organization for users who manage their accounts on their own.
### Create an organisation without existing login
<details open>
<summary>
Example
</summary>
Let's look at our example company `acme.ch`: Suppose ACME sells online-tickets for concert venues. ACME created an organization `iam` to manage their own enterprise users (employees) and projects to manage the provided services. They also created an organization `b2b-partner-1`, allowing the partner self-manage their access. A partner could be a concert venue, that can administrate the backend of the service (e.g. posting new concerts, setting up billing, ...), and you want to allow them to self-manage access of users (e.g. employees of the venue) to their backend. Lastly, the organization `global` holds all the b2c customers of `acme.ch` that registered to the service to buy concert tickets.
</details>
ZITADEL allows you to create a new organisation without a pre-existing user. For [ZITADEL.ch](https://zitadel.ch) you can create a org by visiting the [Register organisation](https://accounts.zitadel.ch/register/org)
### Create an organization without existing login
ZITADEL allows you to create a new organization without a pre-existing user. For [ZITADEL.ch](https://zitadel.ch) you can create a org by visiting the [Register organization](https://accounts.zitadel.ch/register/org)
> Screenshot here
<details>
<summary>
Dedicated Instance
</summary>
For dedicated ZITADEL instances this URL might be different, but in most cases should be something like https://accounts.YOURDOMAIN.TLD/register/org
</details>
### Create an organisation with existing login
### Create an organization with existing login
You can simply create a new organisation by visiting the [ZITADEL Console](https://console.zitadel.ch) and clicking "new organisation" in the upper left corner.
You can simply create a new organization by visiting the [ZITADEL Console](https://console.zitadel.ch) and clicking "new organization" in the upper left corner.
> Screenshot here
<details>
<summary>
Dedicated Instance
</summary>
For dedicated ZITADEL instances this URL might be different, but in most cases should be something like `https://console.YOURDOMAIN.TLD`
</details>
### Verify a domain name
Once you created your organisation you will receive a generated domain name from ZITADEL for your organisation. For example if you call your organisation `ACME` you will receive `acme.zitadel.ch` as name. Furthermore the users you create will be suffixed with this domain name. To improve the user experience you can verify a domain name which you control. If you control acme.ch you can verify the ownership by DNS or HTTP challenge.
Once you created your organization you will receive a generated domain name from ZITADEL for your organization. For example if you call your organization `ACME` you will receive `acme.zitadel.ch` as name. Furthermore the users you create will be suffixed with this domain name. To improve the user experience you can verify a domain name which you control. If you control acme.ch you can verify the ownership by DNS or HTTP challenge.
After the domain is verified your users can use both domain names to log-in. The user "coyote" can now use "coyote@acme.zitadel.ch" and "coyote@acme.ch".
An organisation can have multiple domain names, but only one of it can be primary. The primary domain defines which login name ZITADEL displays to the user, and also what information gets asserted in access_tokens (preferred_username).
An organization can have multiple domain names, but only one of it can be primary. The primary domain defines which login name ZITADEL displays to the user, and also what information gets asserted in access_tokens (preferred_username).
Browse to your [organisation](administrate#Organisations) by visiting [https://console.zitadel.ch/org](https://console.zitadel.ch/org).
Browse to your [organization](administrate#Organizations) by visiting [https://console.zitadel.ch/org](https://console.zitadel.ch/org).
Add the domain to your [organisation](administrate#Organisations) by clicking the button **Add Domain**.
Add the domain to your [organization](administrate#Organizations) by clicking the button **Add Domain**.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_org_domain_default.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_default.png" itemprop="thumbnail" alt="Organisation Overview" />
<img src="img/console_org_domain_default.png" itemprop="thumbnail" alt="Organization Overview" />
</a>
<figcaption itemprop="caption description">Organisation Overview</figcaption>
<figcaption itemprop="caption description">Organization Overview</figcaption>
</figure>
</div>
@ -50,33 +69,33 @@ Input the domain in the input field and click **Add**
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_org_domain_add.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_add.png" itemprop="thumbnail" alt="Organisation Add Domain" />
<img src="img/console_org_domain_add.png" itemprop="thumbnail" alt="Organization Add Domain" />
</a>
<figcaption itemprop="caption description">Organisation Add Domain</figcaption>
<figcaption itemprop="caption description">Organization Add Domain</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_org_domain_added.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_added.png" itemprop="thumbnail" alt="Organisation Domain Added" />
<img src="img/console_org_domain_added.png" itemprop="thumbnail" alt="Organization Domain Added" />
</a>
<figcaption itemprop="caption description">Organisation Domain Added</figcaption>
<figcaption itemprop="caption description">Organization Domain Added</figcaption>
</figure>
</div>
To start the domain verification click the domain name and a dialog will appear, where you can choose between DNS or HTTP challenge methods.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_org_domain_verify.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_verify.png" itemprop="thumbnail" alt="Organisation Domain Verify" />
<img src="img/console_org_domain_verify.png" itemprop="thumbnail" alt="Organization Domain Verify" />
</a>
<figcaption itemprop="caption description">Organisation Domain Verify</figcaption>
<figcaption itemprop="caption description">Organization Domain Verify</figcaption>
</figure>
</div>
For example, create a TXT record with your DNS provider for the used domain and click verify. **ZITADEL** will then proceed an check your DNS.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_org_domain_verify_dns.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_verify_dns.png" itemprop="thumbnail" alt="Organisation Domain Verify DNS" />
<img src="img/console_org_domain_verify_dns.png" itemprop="thumbnail" alt="Organization Domain Verify DNS" />
</a>
<figcaption itemprop="caption description">Organisation Domain Verify DNS</figcaption>
<figcaption itemprop="caption description">Organization Domain Verify DNS</figcaption>
</figure>
</div>
@ -89,7 +108,7 @@ When the verification is successful you have the option to activate the domain b
<a href="img/console_org_domain_verified.png" itemprop="contentUrl" data-size="1920x1080">
<img src="img/console_org_domain_verified.png" itemprop="thumbnail" alt="Organization Domain Verified" />
</a>
<figcaption itemprop="caption description">Organisation verified</figcaption>
<figcaption itemprop="caption description">Organization verified</figcaption>
</figure>
</div>
@ -105,9 +124,11 @@ Congratulations your are done! You can check this by visiting [https://console.z
</figure>
</div>
> This only works when the [user](administrate#Users) is member of this [organisation](administrate#Organisations)
> This only works when the [user](administrate#Users) is member of this [organization](administrate#Organizations)
### Manage Organisation ZITADEL Roles
### Manage Organization ZITADEL Roles
You can assign users [management roles](https://docs.zitadel.ch/administrate#ZITADEL_s_management_Roles) to your new organization.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
@ -124,8 +145,8 @@ Congratulations your are done! You can check this by visiting [https://console.z
</figure>
</div>
### Audit organisation changes
### Audit organization changes
All changes to the organisation are displayed on the organisation menu within [ZITADEL Console](https://console.zitadel.ch/org) organisation menu. Located on the right hand side under "activity".
All changes to the organization are displayed on the organization menu within [ZITADEL Console](https://console.zitadel.ch/org) organization menu. Located on the right hand side under "activity".
> Screenshot here

30
site/docs/administrate/03-projects.en.md
View File

@ -6,28 +6,27 @@ title: 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.
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](administrate#Organisations).
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**
Clients are described here [What are clients](administrate#What_are_clients)
Basically these are your applications who initiate the authorization flow.
These are your applications who initiate the authorization flow (see [What are clients](administrate#What_are_clients)).
**Roles**
[Roles (or Project Roles)](administrate#Roles) is a means of managing users access rights for a certain project.
These [roles](administrate#Roles) are opaque for ZITADEL and have no weight in relation to each other.
So if a [user](administrate#Users) has two roles, admin and user in a certain project, the information will be treated additive.
[Roles (or Project Roles)](administrate#Roles) are a means of managing users access rights for a certain project. These [roles](administrate#Roles) are opaque for ZITADEL and have no weight in relation to each other.
As example, if [user](administrate#Users) 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.
To achieve this the owner of a project can grant (some could say delegate) certain roles or all roles to an organisation.
After granting that organisation it can manage on its own which user has what roles.
This feature is especially useful for service providers, because they are able to establish a great self-service culture for their business customers.
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](administrate#Project_vs_granted_Project).
**Authorizations**
@ -35,8 +34,9 @@ This feature is especially useful for service providers, because they are able t
#### Project vs. granted Project
The simple difference of a project vs a granted project is that a project belongs to your organisation and the granted project belongs to a third party who did grant 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.
A project belongs to your organisation. You can [grant certain roles](administrate#Grant_project_to_a_third_party) 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

12
site/docs/administrate/04-clients.en.md
View File

@ -4,9 +4,17 @@ title: Clients
### What are clients
Clients are applications who share the same security context and interface with an "authorization server".
Clients are applications that share the same security context and interface with an "authorization server" (issuer of access tokens).
For example you could have a software project existing out of a web app and a mobile app, both of these applications might consume the same roles because the end user might use both of them.
Typical types of applications are:
* Web
* User Agent (Single-Page-Application)
* Native
Check out our [Integration Guide](integrate#Overview) for more information.
### Manage clients
Clients might use different protocols for integrating with an IAM. With ZITADEL it is possible to use OpenID Connect 1.0 / OAuth 2.0. In the future SAML 2.0 support is planned as well.
@ -71,4 +79,4 @@ When the wizard is complete, the clients configuration will be displayed and you
</a>
<figcaption itemprop="caption description">Client Wizard Complete</figcaption>
</figure>
</div>
</div>

10
site/docs/administrate/05-roles.en.md
View File

@ -4,7 +4,7 @@ title: Roles
### What are Roles
With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access control**.
**ZITADEL** lets [projects](administrate#projects) define their **role based access control**.
**Roles** can be consumed by the [clients](administrate#clients) which exist within a specific [project](administrate#projects).
@ -24,18 +24,18 @@ Each **role** consist of three fields.
### Granting Roles
To give someone (or somewhat) access to a [projects](administrate#projects) resources and services **ZITADEL** provides to processes. **Roles** can be either granted to [users](administrate#Users) org to [organisations](administrate#Organisations).
To give someone (or somewhat) access to a [project's](administrate#projects) resources and services **ZITADEL** provides two processes: **Roles** can either be granted to [users](administrate#Users) or to [organisations](administrate#Organisations).
#### Grant Roles to Organisations
The possibility to grant **roles** to an [organisation](administrate#Organisations) is intended as "delegation" so that a [org](administrate#Organisations) can on their own grant access to [users](administrate#Users).
The possibility to grant **roles** to an [organisation](administrate#Organisations) is intended as "delegation" so that a [organisation](administrate#Organisations) can on their own grant access to [users](administrate#Users).
For example a **service provider** could grant the **roles** user, and manager to an [org](administrate#Organisations) as soon as they purchases his service. This can be automated by utilising a [service user](administrate#Manage_Service_Users) in the **service providers** business process.
For example a **service provider** could grant the **roles** `user`, and `manager` to an [organisation](administrate#Organisations) as soon as they purchases his service. This can be automated by utilising a [service user](administrate#Manage_Service_Users) in the **service providers** business process.
> Screenshot here
#### Grant Roles to Users
By granting **roles** to [users](administrate#Users), be it [humans or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) receives the authorization to access resources from a service.
By granting **roles** to [users](administrate#Users), be it [humans or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) receives the authorization to access a project's resources.
> Screenshot here

18
site/docs/administrate/06-users.en.md
View File

@ -4,25 +4,27 @@ title: Users
### What are users
In **ZITADEL** there are different [users](administrate#Users). Some belong to dedicated [organisations](administrate#Organisations) other belong to the global [organisations](administrate#Organisations). Some of them are human [users](administrate#Users) others are machines.
In **ZITADEL** there are different [users](administrate#Users). Some belong to dedicated [organisations](administrate#Organisations) other belong to the [global organisation](administrate#Global_organisation). Some of them are human [users](administrate#Users) others are machines.
Nonetheless we treat them all the same in regard to [roles](administrate#Roles) management and audit trail.
#### Human vs. Service Users
The major difference between human vs. machine [users](administrate#Users) is the type of credentials who can be used.
With machine [users](administrate#Users) there is only a non interactive logon process possible. As such we utilize “JWT as Authorization Grant”.
The major difference between human vs. machine [users](administrate#Users) is the type of credentials that can be used: With machine [users](administrate#Users) there is only a non-interactive logon process possible. As such we utilize “JWT as Authorization Grant”.
> TODO Link to “JWT as Authorization Grant” explanation.
### How ZITADEL handles usernames
**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has its own pool of usernames which include human and service [users](administrate#Users).
For example a [user](administrate#Users) with the username `road.runner` can only exist once the [organisation](administrate#Organisations) `ACME`. **ZITADEL** will automatically generate a "logonname" for each [user](administrate#Users) consisting of `{username}@{domainname}.{zitadeldomain}`. Without verifying the domain name this would result in the logonname `road.runner@acme.zitadel.ch`. If you use a dedicated **ZITADEL** replace `zitadel.ch` with your domain name.
**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has its own pool of usernames which includes human and service [users](administrate#Users).
If someone verifies a domain name within the organisation **ZITADEL** will generate additional logonames for each [user](administrate#Users) with that domain. For example if the domain is `acme.ch` the resulting logonname would be `road.runner@acme.ch` and as well the generated one `road.runner@acme.zitadel.ch`.
For example a [user](administrate#Users) with the username `road.runner` can only exist once in the [organisation](administrate#Organisations) `ACME`. **ZITADEL** will automatically generate a "logonname" for each [user](administrate#Users) consisting of `{username}@{domainname}.{zitadeldomain}`. Without [verifying the domain name](administrate#Verify_a_domain_name) this would result in the logonname `road.runner@acme.zitadel.ch`.
> Domain verification also removes the logonname from all [users](administrate#Users who might have used this combination in the global [organisation](administrate#Organisations).
> Relating to example with `acme.ch` if a user in the global [organisation](administrate#Organisations), let's call him `coyote` used `coyote@acme.ch` this logonname will be replaced with `coyote@randomvalue.tld`
> If you use a dedicated instance **ZITADEL** replace `zitadel.ch` with your domain name.
If someone [verifies a domain name](administrate#Verify_a_domain_name) within the organisation, **ZITADEL** will generate additional logonames for each [user](administrate#Users) with the verified domain. For example if the domain is `acme.ch` the resulting logonname would be `road.runner@acme.ch` in addition to the already generated `road.runner@acme.zitadel.ch`.
> Domain verification also removes the logonname from all [users](administrate#Users), who might have used this combination in the [global organisation](administrate#Global_organisation).
> Relating to example with `acme.ch` if a user in the [global organisation](administrate#Global_organisation), let's call him `coyote`, used `coyote@acme.ch` this logonname will be replaced with `coyote@randomvalue.tld`
> **ZITADEL** notifies the user about this change
### Manage Users

21
site/docs/administrate/07-policies.en.md
View File

@ -7,11 +7,13 @@ title: Policies
Policies are a means of enforcing certain behaviour of ZITADEL.
ZITADEL defines a default policy on the system level. However an organisation owner can change these aspects within his own organisation.
### Available policies
Below is a list of available policies
### Password complexity
#### Password complexity
This policy enforces passwords of users within the org. to be compliant.
This policy enforces passwords of users within the organization to be compliant.
- min length
- has number
@ -21,17 +23,18 @@ This policy enforces passwords of users within the org. to be compliant.
> Screenshot here
### IAM Access Preference
#### IAM Access Preference
This policy enforces, when set to true, that usernames are suffixed with the organisations domain.
Under normal operation this policy is only false on the `global` org. so that users can choose their email as their username.
Only available for the `IAM Administrator`
If enabled, this policy enforces that usernames are suffixed with the organisations domain.
Under normal operation this policy is only false on the `global` organisation, so that users can choose their email as their username.
Only available for the [IAM Administrator](administrate#ZITADEL_Administrators).
> Screenshot here
### Login Options
#### Login Options
With this policy it is possible to define what options a user sees in the login process.
With this policy it is possible to define what options a user sees in the login process:
- Username Password allowed
- Self Register allowed
@ -40,7 +43,7 @@ With this policy it is possible to define what options a user sees in the login
> Screenshot here
### Audit policy changes
#### Audit policy changes
> Screenshot here

15
site/docs/administrate/08-providers.en.md
View File

@ -9,7 +9,7 @@ Normally federation uses protocols like [OpenID Connect 1.0](https://openid.net/
Some examples include:
#### Social Providers
**Social Providers**
- Google Account
- Microsoft Live Account
@ -18,13 +18,13 @@ Some examples include:
- GitLab
- ...
#### Enterprise Providers**
**Enterprise Providers**
- Azure AD Tenant
- Gsuite hosted domain
- ...
### Generic
**Generic**
- ADFS
- ADDS
@ -33,8 +33,13 @@ Some examples include:
### What is Identity Brokering
ZITADEL supports the usage as identity broker, by linking multiple external idps into one user.
With identity brokering the client which relies on ZITADEL does not need to care about the linking of identity.
ZITADEL supports the usage as identity broker, by linking multiple external IDPs into one user.
With identity brokering the client, that relies on ZITADEL, doesn't need to care about the linking of identity.
<details>
<summary>Example</summary>
tbd.
</details>
### Manage Identity Providers

8
site/docs/administrate/09-authorisations.en.md
View File

@ -1,12 +1,12 @@
---
title: Authorisations
title: Authorizations
---
### What are Authorisations
### What are Authorizations
**ZITADEL** thinks of authorisations as resource who clearly defines which user has what roles. Authorisations are also called "user grant".
**ZITADEL** thinks of authorizations as resource who clearly defines which user has what roles. Authorizations are also called "user grant".
### Manage Authorisations
### Manage Authorizations
You can grant Roles directly on a project. Or, if the user is in your organisation, by apply in the roles to the user directly.
Additionaly you can use the authorization menu item to search for a user and project.

2
site/docs/administrate/09-authorisations.de.md → site/docs/administrate/09-authorizations.de.md
View File

@ -1,5 +1,5 @@
---
title: Autorisierungen
title: Authorizations
---
> This Language is not yet translated. Please consult the English version.

51
site/docs/administrate/09-authorizations.en.md Normal file
View File

@ -0,0 +1,51 @@
---
title: Authorizations
---
### ZITADEL's management Roles
ZITADEL's own role model is built around the IAM resource. The roles have some hierarchies to them. For example a IAM_OWNER can view and edit every resource of the system. ORG_OWNERS can only manage their resources included within their organisation. This includes projects, clients, users, and so on.
#### How to give a user ZITADEL Roles
With ZITADEL Console
> Screenshots
#### System Roles
IAM_OWNER
IAM_OWNER_VIEWER
#### Organisation Roles
ORG_OWNER
ORG_OWNER_VIEWER
ORG_USER_PERMISSION_EDITOR
ORG_PROJECT_PERMISSION_EDITOR
ORG_PROJECT_CREATOR
#### Owned Project Roles
PROJECT_OWNER
PROJECT_OWNER_VIEWER
PROJECT_OWNER_GLOBAL
PROJECT_OWNER_VIEWER_GLOBAL
#### Granted Project Roles
PROJECT_GRANT_OWNER
PROJECT_GRANT_OWNER_VIEWER
### Project Roles Management
> Explain Project Authorization

2
site/docs/administrate/09-management-roles.de.md
View File

@ -1,5 +1,5 @@
---
title: Authorizations
title: Management Rollen
---
> This Language is not yet translated. Please consult the English version.

18
site/docs/administrate/09-management-roles.en.md
View File

@ -1,23 +1,23 @@
---
title: Authorizations
title: Management roles
---
### ZITADEL's management Roles
### ZITADEL's management roles
ZITADEL's own role model is built around the IAM resource. The roles have some hierarchies to them. For example a IAM_OWNER can view and edit every resource of the system. ORG_OWNERS can only manage their resources included within their organisation. This includes projects, clients, users, and so on.
ZITADEL's own role model is built around the IAM resource. The roles have some hierarchies to them. For example a IAM_OWNER can view and edit every resource of the system. ORG_OWNERS can only manage their resources included within their organization. This includes projects, clients, users, and so on.
#### How to give a user ZITADEL Roles
#### How to give a user ZITADEL roles
> Screenshots
##### System Roles
##### System roles
IAM_OWNER
IAM_OWNER_VIEWER
##### Organisation Roles
##### Organisation roles
ORG_OWNER
@ -29,7 +29,7 @@ ORG_PROJECT_PERMISSION_EDITOR
ORG_PROJECT_CREATOR
##### Owned Project Roles
##### Owned Project roles
PROJECT_OWNER
@ -39,12 +39,12 @@ PROJECT_OWNER_GLOBAL
PROJECT_OWNER_VIEWER_GLOBAL
##### Granted Project Roles
##### Granted Project roles
PROJECT_GRANT_OWNER
PROJECT_GRANT_OWNER_VIEWER
##### Project Roles Management
##### Project roles management
> Explain Project Authorization

2
site/docs/administrate/70-zitadelroles.en.md
View File

@ -42,7 +42,7 @@ PROJECT_GRANT_OWNER_VIEWER
### Manage ZITADEL Roles
You can grant ZITADEL Roles directly on a resource like organisation or project. Or, if the user is in your organisation, by applying in the roles to the user directly.
You can grant ZITADEL Roles directly on a resource like organisation or project. Or, if the user is in your organisation, by applying the roles to the user directly:
- [Manage Organisation ZITADEL Roles](administrate#Manage_Organisation_ZITADEL_Roles)
- [Manage Project ZITADEL Roles](administrate#Manage_Organisation_ZITADEL_Roles)

6
site/docs/integrate/01-singlepageapp.en.md
View File

@ -15,8 +15,6 @@ This flow has great support with most modern languages and frameworks and is the
#### Typescript Authentication Example
---
If you use a framework like Angular, Vue, React, ... you can use this code snippet here to integrate **ZITADEL** into you application
Library used for this example [https://github.com/IdentityModel/oidc-client-js](https://github.com/IdentityModel/oidc-client-js)
@ -61,6 +59,4 @@ export default class AuthService {
});
}
}
```
---
```

2
site/docs/integrate/05-proxy.en.md
View File

@ -94,7 +94,7 @@ spec:
```toml
provider = "oidc"
user_id_claim = "sub" #uses the subject as ID instead of the email
provider_display_name "ZITADEL"
provider_display_name = "ZITADEL"
redirect_url = "http://127.0.0.1:4180/oauth2/callback"
oidc_issuer_url = "https://issuer.zitadel.ch"
upstreams = [

8
site/docs/start/00-quick-start.en.md
View File

@ -5,12 +5,16 @@ description: A quick-start reference for the impatient reader.
> All documentations are under active work and subject to change soon!
### Try ZITADEL
### Trying out ZITADEL
You can either use [ZITADEL.ch](https://zitadel.ch) or deploy a dedicated **ZITADEL** instance.
You can either use our cloud-instance [ZITADEL.ch](https://zitadel.ch) or deploy a dedicated **ZITADEL** instance. To get started, we recommend you try out our free tier on [ZITADEL.ch](https://zitadel.ch).
### Use ZITADEL.ch
To use ZITADEL in your project you need to:
1. Set up a new [client](administrate#What_are_clients) and [users](administrate#What_are_users) in our [Console](administrate#What_is_Console);
2. Configure your project to use ZITADEL.
To register your free [organisation](administrate#Organisations), visit this link [register organisation](https://accounts.zitadel.ch/register/org).
After accepting the TOS and filling out all the required fields you will receive an email with further instructions.

BIN
site/static/img/grafana_client_settings.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 160 KiB

BIN
site/static/img/grafana_login_button.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 302 KiB

BIN
site/static/img/grafana_profile_settings.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 104 KiB

BIN
site/static/img/grafana_project_settings.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 360 KiB

BIN
site/static/img/grafana_zitadel_authorization.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 51 KiB

After

Width:  |  Height:  |  Size: 358 KiB