mirror of
https://github.com/zitadel/zitadel.git
synced 2025-12-08 22:22:39 +00:00
docs: improve documentation for v2 release (#4046)
* WIP: docs(proxy): describe proxy settings * fix nginx * refactor (docs): deploy and operate sections * chore: ignore package-lock since we use yarn * chore: update to rc1 * chore: broken links * chore: update yarn * docs: move disclaimer to bottom * chore: fix broken links * Update docs/docs/guides/operate/tls_modes.mdx Co-authored-by: Fabi <38692350+hifabienne@users.noreply.github.com> * test caddy files * syntax highlight * traefik example * refactor: docs * refactor * working state * got a working state * remove bar * mark rate limits for update * remove zitadel.ch * fix cases * docs: zitadel quickstart * docs: zitadel quickstart * docs: create app and project * docs: move customer portal docs to guides manage cloud * docs: move customer portal docs to guides manage cloud * docs: move customer portal docs to guides manage cloud * docs: add help me choose in the quickstart * docs: broken links * fix broken links * Update knative guide * styling * docs: support customer portal * update to main instead v2-alpha * use version 2 tag * docs: images * docs: move authentication and authorization guides to integrate * docs: quickstart use examples * docs: lb example * fix broken link * docs: update userinfo endpoints * docs: update userinfo endpoints * fix oidc endpoint * docs: remove unused endpoints in app.module Co-authored-by: Fabi <38692350+hifabienne@users.noreply.github.com> Co-authored-by: Fabienne <fabienne.gerschwiler@gmail.com> Co-authored-by: Livio Amstutz <livio.a@gmail.com>
This commit is contained in:
Florian Forster
@@ -7,7 +7,7 @@ This is useful when you have special business requirements that ZITADEL doesn't
|
||||
|
||||
:::caution
|
||||
ZITADEL actions is in an early development stage.
|
||||
In the [roadmap](https://zitadel.ch/roadmap), you see how we are planning to expand and improve it.
|
||||
In the [roadmap](https://zitadel.com/roadmap), you see how we are planning to expand and improve it.
|
||||
Please tell us about your needs and help us prioritize further fixes and features.
|
||||
:::
|
||||
|
||||
@@ -34,5 +34,5 @@ Within the JavaScript code, you can read and manipulate the state.
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Assign users a role after they register using an external identity provider](../../guides/customization/behavior)
|
||||
- [Assign users a role after they register using an external identity provider](../../guides/manage/customize/behavior)
|
||||
- [Actions reference](../../apis/actions)
|
||||
@@ -2,4 +2,4 @@ An instance is the top hierarchy in the ZITADEL.
|
||||
Within an instance all the default [settings](/docs/concepts/structure/policies), such as branding, login policy, password policy, etc. for the system can be configured.
|
||||
One instance normally runs on one domain and has one issuer. (e.g login.customer.com)
|
||||
|
||||
One instance can contain multiple [organizations](./organizations). Which can represent the own company or the customers.
|
||||
One instance can contain multiple [organizations](/docs/concepts/structure/organizations). Which can represent the own company or the customers.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
ZITADEL is organized around the idea that:
|
||||
|
||||
* Multiple organizations can be managed within one [instance](./instance).
|
||||
* Multiple organizations can be managed within one [instance](/docs/concepts/structure/instance).
|
||||
* organizations can grant each other rights to self-manage certain aspects of the IAM (eg, roles for access management)
|
||||
* organizations are vessels for users and projects
|
||||
|
||||
|
||||
@@ -19,4 +19,4 @@ As a fourth option there's the API (OAuth Resource Server), which generally has
|
||||
Depending on the app type registered, there are small differences in the possible settings.
|
||||
|
||||
Please read the following guide about the
|
||||
[different-client-profiles](../../guides/authorization/oauth-recommended-flows#different-client-profiles).
|
||||
[different-client-profiles](../../guides/integrate/oauth-recommended-flows.md#different-client-profiles).
|
||||
|
||||
@@ -97,7 +97,7 @@ You can configure all kinds of external identity providers for identity brokerin
|
||||
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)
|
||||
[Identity Brokering](../../guides/integrate/identity-brokering)
|
||||
|
||||
## Domain policy
|
||||
|
||||
@@ -105,7 +105,7 @@ In the domain policy you have two different settings.
|
||||
One is the "user_login_must_be_domain", by setting this all the users within an organisation will be suffixed with the domain of the organisation.
|
||||
|
||||
The second is "validate_org_domains" if this is set to true all created domains on an organisation must be verified per acme challenge.
|
||||
More about how to verify a domain [here](../../guides/basics/organizations#domain-verification-and-primary-domain).
|
||||
More about how to verify a domain [here](../../guides/manage/console/organizations#domain-verification-and-primary-domain).
|
||||
If it is set to false, all registered domain will automatically be created as verified and the users will be able to use the domain for login.
|
||||
|
||||
## Branding
|
||||
|
||||
@@ -10,7 +10,7 @@ import ProjectDescription from './_project_description.mdx';
|
||||
|
||||
## Project Settings
|
||||
|
||||
On default the login screen will be shown in the private labeling settings of the system (e.g zitadel.ch).
|
||||
On default the login screen will be shown in the private labeling settings of the system.
|
||||
With the [primary domain scope](../../apis/openidoauth/scopes#reserves-scopes) it is possible to trigger the setting of the given organization.
|
||||
But this will also restrict, the login to user of the given organization.
|
||||
|
||||
@@ -18,7 +18,7 @@ With the private labeling setting it is possible to choose which settings should
|
||||
|
||||
| Setting | Description |
|
||||
| --- | --- |
|
||||
| Unspecified | If nothing is specified the default will trigger. (System settings zitadel.ch) |
|
||||
| Unspecified | If nothing is specified the default will trigger. (System settings) |
|
||||
| Enforce project resource owner policy | This setting will enforce the private labeling of the organization (resource owner) of the project through the whole login process. |
|
||||
| Allow Login User resource owner policy | With this setting first the private labeling of the organization (resource owner) of the project will trigger. As soon as the user and its organization (resource owner) is identified by ZITADEL, the settings will change to the organization of the user. |
|
||||
|
||||
|
||||
@@ -67,5 +67,5 @@ If the setting is set to `Ensure Project Resource Owner Setting`, the private la
|
||||
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)
|
||||
More about [Private Labeling](../../guides/manage/customize/branding)
|
||||
:::
|
||||
Reference in New Issue
Block a user