fix: Domains problematic (#6564)

* docs: disable validate org domains per default, and have a better label

* docs: rename to $CUSTOM-DOMAIN

* docs: translation

* docs: tranlsations

* docs: tranlsations

* docs: allow domain discovery

---------

Co-authored-by: Max Peintner <max@caos.ch>
This commit is contained in:
Fabi
2023-09-20 12:45:11 +02:00
committed by GitHub
parent 57d8ff1ef6
commit 7edc73bd5e
41 changed files with 109 additions and 109 deletions

View File

@@ -46,7 +46,7 @@ JWT
| Claim | Example | Description |
|:------|:---------------------------|:----------------------------------------------------------------------------------------------------------------|
| aud | `"https://{your_domain}"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| aud | `"https://$CUSTOM-DOMAIN"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| exp | `1605183582` | Unix timestamp of the expiry |
| iat | `1605179982` | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h |
| iss | `"78366401571920522@acme"` | String which represents the requesting party (owner of the key), normally the `clientID` from the json key file |
@@ -56,7 +56,7 @@ JWT
{
"iss": "78366401571920522@acme",
"sub": "78366401571920522@acme",
"aud": "https://{your_domain}",
"aud": "https://$CUSTOM-DOMAIN",
"exp": 1605183582,
"iat": 1605179982
}

View File

@@ -43,7 +43,7 @@ Please check below the matrix for an overview where which scope is asserted.
| Claims | Example | Description |
|:-------------------|:-----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
| acr | TBA | TBA |
| address | `Lerchenfeldstrasse 3, 9014 St. Gallen` | TBA |
| address | `Lerchenfeldstrasse 3, 9014 St. Gallen` | TBA |
| amr | `pwd mfa` | Authentication Method References as defined in [RFC8176](https://tools.ietf.org/html/rfc8176) <br/> `password` value is deprecated, please check `pwd` |
| aud | `69234237810729019` | The audience of the token, by default all client id's and the project id are included |
| auth_time | `1311280969` | Unix time of the authentication |
@@ -55,7 +55,7 @@ Please check below the matrix for an overview where which scope is asserted.
| gender | `other` | Gender of the subject |
| given_name | `Road` | Given name of the subject |
| iat | `1311280970` | Time of the token was issued at (as unix time) |
| iss | `{your_domain}` | Issuing domain of a token |
| iss | `$CUSTOM-DOMAIN` | Issuing domain of a token |
| jti | `69234237813329048` | Unique id of the token |
| locale | `en` | Language from the subject |
| name | `Road Runner` | The subjects full name |

View File

@@ -76,19 +76,19 @@ Key JSON
JWT
| Claim | Example | Description |
|:------|:--------------------------|:--------------------------------------------------------------------------------------------------------------|
| aud | `"https://{your_domain}"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| exp | `1605183582` | Unix timestamp of the expiry |
| iat | `1605179982` | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h |
| iss | `"77479219772321307"` | String which represents the requesting party (owner of the key), normally the `userId` from the json key file |
| sub | `"77479219772321307"` | The subject ID of the service user, normally the `userId` from the json key file |
| Claim | Example | Description |
|:------|:-------------------------|:--------------------------------------------------------------------------------------------------------------|
| aud | `"https://$CUSTOM-DOMAIN"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| exp | `1605183582` | Unix timestamp of the expiry |
| iat | `1605179982` | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h |
| iss | `"77479219772321307"` | String which represents the requesting party (owner of the key), normally the `userId` from the json key file |
| sub | `"77479219772321307"` | The subject ID of the service user, normally the `userId` from the json key file |
```JSON
{
"iss": "77479219772321307",
"sub": "77479219772321307",
"aud": "https://{your_domain}",
"aud": "https://$CUSTOM-DOMAIN",
"exp": 1605183582,
"iat": 1605179982
}

View File

@@ -4,7 +4,7 @@ title: SAML Endpoints in ZITADEL
## SAML 2.0 metadata
The SAML Metadata is located within the issuer domain. This would give us {your_domain}/saml/v2/metadata.
The SAML Metadata is located within the issuer domain. This would give us $CUSTOM-DOMAIN/saml/v2/metadata.
This metadata contains all the information defined in the spec.
@@ -13,14 +13,14 @@ spec.** [Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0
## Certificate endpoint
{your_domain}/saml/v2/certificate
$CUSTOM-DOMAIN/saml/v2/certificate
The certificate endpoint provides the certificate which is used to sign the responses for download, for easier use with
different service providers which want the certificate separately instead of inside the metadata.
## SSO endpoint
{your_domain}/saml/v2/SSO
$CUSTOM-DOMAIN/saml/v2/SSO
The SSO endpoint is the starting point for all initial user authentications. The user agent (browser) will be redirected
to this endpoint to authenticate the user.

View File

@@ -27,7 +27,7 @@ The same view is available on several other objects such as organization or proj
### Event View
Administrators can see all events across an instance and filter them directly in [Console](/docs/guides/manage/console/overview).
Go to your instance settings and then click on the Tab **Events** to open the Event Viewer or browse to $YOUR_DOMAIN/ui/console/events
Go to your instance settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM-DOMAIN/ui/console/events
![Event viewer](/img/concepts/audit-trail/event-viewer.png)

View File

@@ -139,7 +139,7 @@ A client can also implement this, by calling the [specific endpoint](/apis/openi
## Profile
These actions are available for authenticated users only.
ZITADEL provides a self-service UI for the user profile out-of-the box under the path _{your_domain}/ui/console/users/me_.
ZITADEL provides a self-service UI for the user profile out-of-the box under the path _$CUSTOM-DOMAIN/ui/console/users/me_.
You can also implement your own version in your application by using our APIs.
### Change password

View File

@@ -43,7 +43,7 @@ provider = "oidc"
user_id_claim = "sub" #uses the subject as ID instead of the email
provider_display_name = "ZITADEL"
redirect_url = "http://127.0.0.1:4180/oauth2/callback"
oidc_issuer_url = "https://{your_domain}.zitadel.cloud"
oidc_issuer_url = "https://$CUSTOM-DOMAIN"
upstreams = [
"https://example.corp.com"
]

View File

@@ -44,7 +44,7 @@ Use the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to include the ZITADE
```bash
curl --request POST \
--url {your_domain}/oauth/v2/token \
--url $CUSTOM-DOMAIN/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer \
--data scope='openid profile email urn:zitadel:iam:org:project:id:zitadel:aud' \

View File

@@ -59,7 +59,7 @@ The JWT payload will need to contain the following claims:
{
"iss": "<userid>",
"sub": "<userid>",
"aud": "<https://your_domain>",
"aud": "<https://$CUSTOM-DOMAIN>",
"exp": <now+1h>,
"iat": <now>
}
@@ -95,7 +95,7 @@ Now that you configured ZITADEL and created a JWT, you can call the System API a
```bash
curl --request POST \
--url {your_domain}/system/v1/instances/_search \
--url $CUSTOM-DOMAIN/system/v1/instances/_search \
--header 'Authorization: Bearer {token}' \
--header 'Content-Type: application/json'
```

View File

@@ -29,7 +29,7 @@ Configure ZITADEL as your _Custom JWT Provider_ following the [MongoDB docs](htt
Configure the following values:
- Signing Algorithm: RS256
- Signing Key: JWK or JWKS URL
- JWKS: https://{your_domain}.zitadel.cloud/oauth/v2/keys
- JWKS: https://$CUSTOM-DOMAIN/oauth/v2/keys
- Audience: Your app's client ID which you copied when you created the ZITADEL app
Your configuration should look similar to this:

View File

@@ -41,7 +41,7 @@ You will need to craft a POST request to ZITADEL's token endpoint:
```bash
curl --request POST \
--url https://{your_domain}.zitadel.cloud/oauth/v2/token \
--url https://$CUSTOM-DOMAIN/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ${BASIC_AUTH}' \
--data grant_type=client_credentials \
@@ -72,7 +72,7 @@ In this example we read the organization of the service user.
```bash
curl --request GET \
--url {your-domain}/management/v1/orgs/me \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--header 'Authorization: Bearer ${TOKEN}'
```

View File

@@ -24,7 +24,7 @@ To further restrict your result you can add the following filters:
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/events/_search \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN"
```
@@ -34,7 +34,7 @@ To be able to filter for the different event types ZITADEL knows, you can reques
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/events/types/_search \
--url $CUSTOM-DOMAIN/admin/v1/events/types/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
'
@@ -70,7 +70,7 @@ To be able to filter for the different aggregate types (resources) ZITADEL knows
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/aggregates/types/_search \
--url $CUSTOM-DOMAIN/admin/v1/aggregates/types/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json'
```
@@ -101,7 +101,7 @@ This example shows you how to get all events from users, filtered with the creat
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/events/_search \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
@@ -121,7 +121,7 @@ Also we include the refresh tokens in this example to know when the user has bec
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/events/_search \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
@@ -147,7 +147,7 @@ In this case this are the following events:
```bash
curl --request POST \
--url $YOUR-DOMAIN/admin/v1/events/_search \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{

View File

@@ -37,7 +37,7 @@ If you have specified some post_logout_redirect_uris on your client you have to
So ZITADEL is able to read the configured redirect uris.
```
GET {your_domain}/oidc/v1/end_session
GET $CUSTOM-DOMAIN/oidc/v1/end_session
?id_token_hint={id_token}
&post_logout_redirect_uri=https://rp.example.com/logged_out
&state=random_string

View File

@@ -41,6 +41,6 @@ In this example we read the organization of the service user.
```bash
curl --request GET \
--url {your-domain}/management/v1/orgs/me \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--header 'Authorization: Bearer {PAT}'
```

View File

@@ -68,7 +68,7 @@ Payload
{
"iss": "100507859606888466",
"sub": "100507859606888466",
"aud": "https://{your_domain}.zitadel.cloud",
"aud": "https://$CUSTOM-DOMAIN",
"iat": [Current UTC timestamp, e.g. 1605179982, max. 1 hour ago],
"exp": [UTC timestamp, e.g. 1605183582]
}
@@ -90,7 +90,7 @@ With the encoded JWT from the prior step, you will need to craft a POST request
```bash
curl --request POST \
--url https://{your_domain}.zitadel.cloud/oauth/v2/token \
--url https:/$CUSTOM-DOMAIN/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer \
--data scope='openid profile email' \
@@ -122,7 +122,7 @@ For this example let's call the userinfo endpoint to verify that our access toke
```bash
curl --request POST \
--url https://{your_domain}.zitadel.cloud/oidc/v1/userinfo \
--url $CUSTOM-DOMAIN/oidc/v1/userinfo \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Bearer MtjHodGy4zxKylDOhg6kW90WeEQs2q...'
```
@@ -135,7 +135,7 @@ Content-Type: application/json
{
"name": "MyServiceUser",
"preferred_username": "service_user@{your_domain}.zitadel.cloud",
"preferred_username": "service_user@$CUSTOM-DOMAIN",
"updated_at": 1616417938
}
```

View File

@@ -83,7 +83,7 @@ Alternatively, you can include the claims `urn:iam:org:project:roles` or/and `ur
### Retrieve roles from the userinfo endpoint
The user info endpoint is **ZITADEL_DOMAIN/oidc/v1/userinfo**.
The user info endpoint is **$CUSTOM-DOMAIN/oidc/v1/userinfo**.
This endpoint will return information about the authenticated user.
Send the access token of the user as `Bearer Token` in the `Authorization` header:
@@ -91,7 +91,7 @@ Send the access token of the user as `Bearer Token` in the `Authorization` heade
**cURL Request:**
```bash
curl --request GET \
--url $ZITADEL_DOMAIN/oidc/v1/userinfo
--url $CUSTOM-DOMAIN/oidc/v1/userinfo
--header 'Authorization: Bearer <TOKEN>'
```
@@ -206,11 +206,11 @@ Lets start with a user who has multiple roles in different organizations in a
Returns a list of roles for the authenticated user and for the requesting project (based on the token).
**URL: https://$ZITADEL_DOMAIN/auth/v1/permissions/me/_search**
**URL: https://$CUSTOM-DOMAIN/auth/v1/permissions/me/_search**
**cURL request:**
```bash
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/me/_search' \
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/permissions/me/_search' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>'
```
@@ -231,12 +231,12 @@ Returns a list of permissions the authenticated user has in ZITADEL based on the
This request can be used if you are building a management UI. For instance, if the UI is managing users, you can show the management functionality based on the permissions the user has. Heres an example: if the user has `user.read` and `user.write` permission you can show the edit buttons, if the user only has `user.read` permission, you can hide the edit buttons.
**URL: https://ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search**
**URL: https://$CUSTOM-DOMAIN/auth/v1/permissions/zitadel/me/_search**
**cURL Request:**
```bash
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search' \
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/permissions/zitadel/me/_search' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>'
```
@@ -277,12 +277,12 @@ curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search'
Returns a list of user grants the authenticated user has. User grants consist of an organization, a project and roles.
**URL: https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search**
**URL: https://$CUSTOM-DOMAIN/auth/v1/usergrants/me/_search**
**cURL request:**
```bash
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search' \
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/usergrants/me/_search' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -379,7 +379,7 @@ curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search' \
### Retrieve roles using the management API
Now we will use the management API to retrieve user roles under an admin user.
The base URL is: **https://$ZITADEL_DOMAIN/management/v1**
The base URL is: **https://$CUSTOM-DOMAIN/management/v1**
In [APIs listed under user grants in the management API](/docs/category/apis/resources/mgmt/user-grants), you will see that you can use the management API to retrieve and modify user grants. The two API paths that we are interested in to fetch user roles are given below.
@@ -389,12 +389,12 @@ In [APIs listed under user grants in the management API](/docs/category/apis/res
Returns a list of user roles that match the search queries. A user with manager permissions will call this API and will also have to reside in the same organization as the user.
**URL: https://$ZITADEL_DOMAIN/management/v1/users/grants/_search**
**URL: https://$CUSTOM-DOMAIN/management/v1/users/grants/_search**
**cURL request:**
```bash
curl -L -X POST 'https://$ZITADEL_DOMAIN/management/v1/users/grants/_search' \
curl -L -X POST 'https://$CUSTOM-DOMAIN/management/v1/users/grants/_search' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \

View File

@@ -51,7 +51,7 @@ Check your application, if everything is correct, press "Create".
Complete the configuration as follows:
- `Identity provider single sign-on URL`: {your_instance_domain}/saml/v2/SSO
- `Identity provider single sign-on URL`: $CUSTOM-DOMAIN/saml/v2/SSO
- `Certificate fingerprint`: You need to download the certificate from {your_instance_domain}/saml/v2/certificate and create a SHA1 fingerprint
Save the changes.

View File

@@ -56,7 +56,7 @@ A free instance can be upgraded to a "pay as you go" instance. By upgrading your
### Add Custom Domain
We recommend register a custom domain to access your ZITADEL instance.
The primary domain of your ZITADEL instance will be the issuer of the instance. All other domains can be used to access the instance itself
The primary custom domain of your ZITADEL instance will be the issuer of the instance. All other custom domains can be used to access the instance itself
1. Browse to your instance
2. Click **Add custom domain**
@@ -73,7 +73,7 @@ Be aware that it has some impacts if you change the primary domain of your insta
![Add custom domain](/img/manuals/portal/portal_add_domain.png)
#### Verify Domain
#### Verify Custom Domain
If you need a custom domain for your ZITADEL instance, you need to verify the domain.

View File

@@ -23,7 +23,7 @@ If you choose your logged in user as organization manager, a membership for the
alt="Select Organization"
/>
If you want to enable your customers to create their organization by themselves, we provide a creation form for a organization. `<https://{your-domain}-{random string}.zitadel.cloud/ui/login/register/org`
If you want to enable your customers to create their organization by themselves, we provide a creation form for a organization. `<https://$CUSTOM-DOMAIN/ui/login/register/org`
The customer needs to fill in the form with the organization name and the contact details.
<img

View File

@@ -50,7 +50,7 @@ Request the user information by calling the [userinfo endpoint](/docs/apis/openi
```bash
curl --request GET \
--url "https://$ZITADEL_DOMAIN/oidc/v1/userinfo" \
--url "https://$CUSTOM-DOMAIN/oidc/v1/userinfo" \
--header "Authorization: Bearer $ACCESS_TOKEN"
```
@@ -166,7 +166,7 @@ If you get the error "invalid audience (APP-Zxfako)", then you need to add the r
You can request the user's metadata with the [List My Metadata](/docs/apis/resources/auth/auth-service-list-my-metadata) method:
```bash
curl -L -X POST "https://$ZITADEL_DOMAIN/auth/v1/users/me/metadata/_search" \
curl -L -X POST "https://$CUSTOM-DOMAIN/auth/v1/users/me/metadata/_search" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -188,7 +188,7 @@ curl -L -X POST "https://$ZITADEL_DOMAIN/auth/v1/users/me/metadata/_search" \
```
Replace `$ACCESS_TOKEN` with your user's access token.
Replace `$ZITADEL_DOMAIN` with your ZITADEL instance's url.
Replace `$CUSTOM-DOMAIN` with your ZITADEL instance's url.
Replace `$METADATA_KEY` with they key you want to search for (f.e. "ContractNumber")
:::info Get all metadata