mirror of
https://github.com/zitadel/zitadel.git
synced 2025-12-09 01:32:56 +00:00
docs: restructure and add more content (#2232)
* docs: restructure quickstarts * docs: quickstart libs * docs: add exlixir lib * docs: restructure * docs: restructure * docs: customization * use tabs in oauth/oidc endpoints.md * improve authorize_endpoint * improve token_endpoint and introspection_endpoint * docs: saas use case * styling * styling * begin login users * login users * login users * fix table * fix: links * fix: links * start go api * fix: policy structure * fix: saas description * fix: saas description * fix: saas description * Update docs/docs/concepts/policies.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * Update docs/docs/concepts/usecases/saas.md Co-authored-by: mffap <mpa@caos.ch> * docs: organisation --> organization * docs: fixes * docs: fixes * Update docs/docs/apis/openidoauth/endpoints.md Co-authored-by: Florian Forster <florian@caos.ch> * Update docs/docs/concepts/policies.md Co-authored-by: Florian Forster <florian@caos.ch> * Update docs/docs/concepts/policies.md Co-authored-by: Florian Forster <florian@caos.ch> * Update docs/docs/concepts/policies.md Co-authored-by: Florian Forster <florian@caos.ch> * Update docs/docs/apis/openidoauth/endpoints.md Co-authored-by: Florian Forster <florian@caos.ch> * Apply suggestions from code review Co-authored-by: Florian Forster <florian@caos.ch> * docs: intro * Update docs/docs/guides/customization/branding.md Co-authored-by: Florian Forster <florian@caos.ch> * fix: typo * add mermaid Co-authored-by: Livio Amstutz <livio.a@gmail.com> Co-authored-by: mffap <mpa@caos.ch> Co-authored-by: Florian Forster <florian@caos.ch>
This commit is contained in:
Fabi
@@ -2,11 +2,6 @@
|
||||
title: Introduction
|
||||
---
|
||||
|
||||
> All documentations are under active work and subject to change soon!
|
||||
|
||||
This part of the **ZITADEL** documentation comprises twoo major subject areas:
|
||||
|
||||
1. ZITADEL Architecture
|
||||
2. Principles
|
||||
This part of the **ZITADEL** documentation contains ZITADEL specific or general concepts required to understand the system or our guides.
|
||||
|
||||
Please be reminded that ZITADEL is open source — and so is the documentation. Should you happen to stumble over an incorrectness, a spelling mistake, a hard-to-understand text passage, please don’t hesitate to leave a comment or propose a corresponding change.
|
||||
|
||||
30
docs/docs/concepts/managers.md
Normal file
30
docs/docs/concepts/managers.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: ZITADEL Managers
|
||||
---
|
||||
|
||||
ZITADEL Managers are Users who have permission to manage ZITADEL itself. There are some different levels for managers.
|
||||
|
||||
- **IAM Managers**: This is the highest level. Users with IAM Manager roles are able to manage the whole IAM.
|
||||
- **Org Managers**: Managers in the Organization Level are able to manage everything within the granted Organization.
|
||||
- **Project Mangers**: In this level the user is able to manage a project.
|
||||
- **Project Grant Manager**: The project grant manager is for projects, which are granted of another organization.
|
||||
|
||||
To configure managers in ZITADEL go to the resource where you like to add it (e.g IAM, Organization, Project, GrantedProject).
|
||||
In the right part of the console you can finde **MANAGERS** in the details part. Here you have a list of the current managers and can add a new one.
|
||||
|
||||
## Roles
|
||||
|
||||
| Role | Description |
|
||||
|---|---|
|
||||
| IAM_OWNER | Manage the IAM, manage all organizations with their content |
|
||||
| IAM_OWNER_VIEWER | View the IAM and view all organizations with their content |
|
||||
| ORG_OWNER | Manage everything within an organization |
|
||||
| ORG_OWNER_VIEWER | View everything within an organization |
|
||||
| ORG_USER_PERMISSION_EDITOR | Manage user grants and view everything needed for this |
|
||||
| ORG_PROJECT_PERMISSION_EDITOR | Grant Projects to other organizations and view everything needed for this |
|
||||
| ORG_PROJECT_CREATOR | This role is used for users in the global organization. They are allowed to create projects and manage them. |
|
||||
| PROJECT_OWNER | Manage everything within a project. This includes to grant users for the project. |
|
||||
| PROJECT_OWNER_VIEWER | View everything within a project.|
|
||||
| PROJECT_OWNER_GLOBAL | Same as PROJECT_OWNER, but in the global organization. |
|
||||
| PROJECT_OWNER_VIEWER_GLOBAL | Same as PROJECT_OWNER_VIEWER, but in the global organization. |
|
||||
| PROJECT_GRANT_OWNER | Same as PROJECT_OWNER but for a granted proejct. |
|
||||
85
docs/docs/concepts/policies.md
Normal file
85
docs/docs/concepts/policies.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: ZITADEL Policies
|
||||
---
|
||||
|
||||
Policies are configurations of all the different parts of the IAM. For all parts we have a suitable default in the IAM.
|
||||
The default configuration can be overridden for each organization.
|
||||
|
||||
## General
|
||||
|
||||
You can find these settings in the menu organization in the section polcies.
|
||||
Each policy can be overridden and reset to the default.
|
||||
|
||||
## Password Complexity
|
||||
|
||||
With the password complexity policy you can define the requirements for a users password.
|
||||
|
||||
The following properties can be set:
|
||||
- Minimum Length
|
||||
- Has Uppercase
|
||||
- Has Lowercase
|
||||
- Has Number
|
||||
- Has Symbol
|
||||
|
||||
|
||||
|
||||
## Login Policy
|
||||
|
||||
The Login Policy defines how the login process should look like and which authentication options a user has to authenticate.
|
||||
|
||||
| Setting | Description |
|
||||
| --- | --- |
|
||||
| Register allowed | Enable self register possibility in the login ui |
|
||||
| Username Password allowed | Possibility to login with username and password |
|
||||
| External IDP allowed | Possibility to login with an external identity (e.g Google, Microsoft, Apple, etc)|
|
||||
| Force MFA | Force a user to register and use a multifactor authentication |
|
||||
| Passwordless | Choose if passwordless login is allowed or not |
|
||||
|
||||
|
||||
|
||||
### Multifactors / Second Factors
|
||||
|
||||
In the multifactors section you can configure what kind of multifactors should be allowed. For passwordless to work, it's required to enable U2F (Universial Second Factor) with PIN. There is no other option at the moment.
|
||||
Multifactors:
|
||||
- U2F (Universal Second Factor) with PIN
|
||||
|
||||
Secondfactors:
|
||||
- OTP (One Time Password)
|
||||
- U2F (Universal Second Factor)
|
||||
|
||||
|
||||
|
||||
### Identity Providers
|
||||
|
||||
You can configure all kinds of external identity providers for identity brokering, which support OIDC (OpenID Connect).
|
||||
Create a new identity provider configuration and enable it in the list afterwards.
|
||||
|
||||
For a detailed guide about how to configure a new identity provider for identity brokering have a look at our guide:
|
||||
[Identity Brokering](../guides/authentication/identity-brokering)
|
||||
|
||||
## Lockout Policy
|
||||
|
||||
Define when an account should be locked.
|
||||
|
||||
The following settings are available:
|
||||
- Maximum Password Attempts: When the user has reached the maximum password attempts the account will be locked
|
||||
|
||||
If an account is locked, the administrator has to unlock it in the ZITADEL console
|
||||
|
||||
|
||||
## Private Labeling / Branding
|
||||
|
||||
With private labeling you can brand and customize your login page and emails, that it matches your CI/CD.
|
||||
You can configure a light and a dark design.
|
||||
|
||||
Make sure you click the "Set preview as current configuration" button after you finish your configuration. Before this it will only be set as your preview configuration.
|
||||
|
||||
| Setting | Description |
|
||||
| --- | --- |
|
||||
| Logo | Upload your logo for the light and the dark design. |
|
||||
| Colors | You can set four different colors to design your login page and email. (Background-, Primary-, Warn- and Font Color) |
|
||||
| Font | Upload your custom font |
|
||||
| Hide Loginname suffix | If enabled, your loginname suffix (Domain) will not be shown in the login page |
|
||||
| Disable Watermark | If you disable the watermark you will not see the "Powered by ZITADEL" in the login page |
|
||||
|
||||
|
||||
79
docs/docs/concepts/usecases/saas.md
Normal file
79
docs/docs/concepts/usecases/saas.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: Saas Product with Authentication and Authorization
|
||||
---
|
||||
|
||||
This is an example architecture for a typical SaaS product.
|
||||
To illustrate it, a fictional organization and project is used.
|
||||
|
||||
## Example Case
|
||||
|
||||
The Timing Company has a product called Time.
|
||||
They have two environments, the development and the production environment.
|
||||
In this case Time uses authentication and authorizations from ZITADEL.
|
||||
This means that the users and also their authorizations will be managed within ZITADEL.
|
||||
|
||||
|
||||
|
||||
## Organization
|
||||
|
||||
An organization is the ZITADEL resource which contains users, projects, applications, policies and so on.
|
||||
In an organization projects and users are managed by the organization.
|
||||
You need at least one organization for your own company in our case "The Timing Company".
|
||||
|
||||
For your customers you have different possibilities:
|
||||
1. Your customer already owns an organization in ZITADEL
|
||||
2. Your customer creates a new organization in ZITADEL by itself
|
||||
3. You create an organization for your customer (If you like to verify the domain, the customer has to do it)
|
||||
|
||||
:::info
|
||||
Subscriptions are organization based. This means, that each organization can choose their own tier based on the needed features.
|
||||
:::
|
||||
|
||||
## Project
|
||||
|
||||
The idea of projects is to have a vessel for all components who are closely related to each other.
|
||||
|
||||
In this use case we would have two different projects, for each environment one. So lets call it "Time Dev" and "Time Prod".
|
||||
These projects should be created in "The Timing Company" organization, because it is the owner of the project.
|
||||
|
||||
In the project you will configure all your roles and applications (clients and APIs).
|
||||
|
||||
### Project Settings
|
||||
|
||||
You can configure `check roles on authentication` on the project, if you want to restrict access to users that have the correct authorization for the project.
|
||||
|
||||
### Project Grant
|
||||
|
||||
To give a customer permissions to a project, a project grant to the customers organization is needed (search the granted organization by its domain).
|
||||
It is also possible to delegate only specific roles of the project to a certain customer.
|
||||
As soon as a project grant exists, the customer will see the project in the granted projects section of his organization and will be able to authorize his own users to the given project.
|
||||
|
||||
## Authorizations
|
||||
|
||||
To give a user permission to a project an authorization is needed.
|
||||
All organizations which own the project or received a grant are able to authorize users.
|
||||
It is also possible to authorize users outside the own company if the exact login name of the user is known.
|
||||
|
||||
## Project Login
|
||||
|
||||
There are some different use cases how the login should behave and look like:
|
||||
|
||||
1. Restrict Organization
|
||||
|
||||
With the primary domain scope the organization will be restricted to the requested domain, this means only users of the requestd organization will be able to login.
|
||||
The private labeling (branding) and the login policy of the requested organization will be set automatically.
|
||||
|
||||
:::note
|
||||
More about the [Scopes](../../apis/openidoauth/scopes)
|
||||
:::
|
||||
|
||||
2. Show private labeling (branding) of the project organization
|
||||
|
||||
You can configure on project-level which branding should be shown to users.
|
||||
In the default the design of ZITADEL will be shown, but as soon as the user is identified, the policy of the users organization will be triggered.
|
||||
If the setting is set to `Ensure Project Resource Owner Setting`, the private labeling of the project organization will always be triggered.
|
||||
The last possibility is to show the private labeling of the project organization and as soon as the user is identitfied the user organization settings will be triggered.
|
||||
For this the Allow User Resource Owner Setting should be set.
|
||||
:::note
|
||||
More about [Private Labeling](../../guides/customization/branding)
|
||||
:::
|
||||
Reference in New Issue
Block a user