TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2025-02-28 12:17:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: spell check automation and spellcheck (#889)

Browse Source 
* test spell check

* fix indenting

* test

* add something to test

* test spellcheck

* spelling improvements

* improve spelling and ignore list

* Update site/docs/start/00-quick-start.de.md
This commit is contained in:
Florian Forster 2020-10-26 13:54:29 +01:00 committed by GitHub
parent 22d4c345be
commit 9f0638fac9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 104 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
.github/workflows/spellcheck.yml vendored Normal file
View File

@ -0,0 +1,19 @@
name: Spellcheck
on:
push:
branches: [master]
pull_request:
branches: [master]
jobs:
spellcheck:
name: Typo CI (GitHub Action)
runs-on: ubuntu-latest
timeout-minutes: 4
if: "!contains(github.event.head_commit.message, '[ci skip]')"
steps:
- name: TypoCheck
uses: typoci/spellcheck-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

40
.typo-ci.yml Normal file
View File

@ -0,0 +1,40 @@
# What language dictionaries should it use? Currently Typo CI supports:
# de
# en
# en_GB
# es
# fr
# it
# pt
# pt_BR
dictionaries:
- en
- en_GB
- de
# Any files/folders we should ignore?
excluded_files:
- ".codecov/*"
- ".github/*"
- "build/*"
- "k8s/*"
- "*.min.css"
- "*.css.map"
- "*.min.js"
- "*.js.map"
- "package-lock.json"
- "package.json"
- ".releaserc.js"
- ".typo-ci.yml"
- ".gitignore"
- "go.mod"
- "go.sum"
# Any typos we should ignore?
excluded_words:
- typoci
- idps
- ZITADEL's
# Would you like filenames to also be spellchecked?
spellcheck_filenames: false

2
site/README.md
View File

@ -13,6 +13,6 @@ npm i
Start the server with `npm run dev`, and navigate to [localhost:3000](http://localhost:3000).
### Honorable Mentions
## Honorable Mentions
This project was created with the help of some components from [svelte](https://github.com/sveltejs/svelte)([MIT](https://github.com/sveltejs/svelte/blob/master/LICENSE)) as well as [site-kit](https://github.com/sveltejs/site-kit)([MIT](https://github.com/sveltejs/site-kit/blob/master/LICENSE)).

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

@ -6,7 +6,7 @@ title: Console
Console is the ZITADEL Graphical User Interface.
**Users** can manage some information by their own.
**Users** can manage some information on their own.
- profile information
- credentials

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

@ -70,8 +70,7 @@ To start the domain verification click the domain name and a dialog will appear,
<figcaption itemprop="caption description">Organisation Domain Verify</figcaption>
</figure>
</div>
For example, create a TXT record with your DNS provider for the used domain an click verify. **ZITADEL** will then proceed an check your DNS.
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">
@ -81,7 +80,6 @@ For example, create a TXT record with your DNS provider for the used domain an c
</figure>
</div>
> Do not delete the verification code **ZITADEL** will recheck the ownership from time to time
When the verification is successful you have the option to activate the domain by clicking **Set as primary**
@ -97,8 +95,7 @@ When the verification is successful you have the option to activate the domain b
> This changes the **preferred loginnames** of your [users](administrate#Users) as indicated [here](administrate#How_ZITADEL_handles_usernames).
Gratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
Congratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
<a href="img/console_user_personal_info.png" itemprop="contentUrl" data-size="1920x1080">

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

@ -6,7 +6,7 @@ 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 a access management perspective you manage who has what role in the project and your application consume this information.
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.
@ -14,18 +14,18 @@ With the project role check you can define if a user should have a requested rol
**Clients**
Clients are described here [What are clients](administrate#What_are_clients)
Basically these are you applications who initiate the authorization flow.
Basically these are your applications who initiate the authorization flow.
**Roles**
[Roles (or Project Roles)](administrate#Roles) is a mean of managing users access rights for a certain project.
[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.
**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 a organisation.
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.
@ -34,7 +34,7 @@ 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 easily to differentiate ZITADEL Console displays these both as separate menu in the project section.
To make it more easier to differentiate, ZITADEL Console displays these both as separate menu in the project section.
### Manage a project
@ -51,7 +51,7 @@ To create your project go to [https://console.zitadel.ch/projects](https://conso
</figure>
</div>
Create a new project with name which explains what's the intended use of this project.
Create a new project with a name which explains what's the intended use of this project.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">

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

@ -5,7 +5,7 @@ title: Clients
### What are clients
Clients are applications who share the same security context and interface with an "authorization server".
For example you could have a software project existing out of a web app and a mobile app, both of these application might consume the same roles because the end user might use both of them.
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.
### Manage clients

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

@ -4,11 +4,11 @@ title: Roles
### What are Roles
With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access controle**.
With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access control**.
**Roles** can be consumed by the [clients](administrate#clients) which exist witing a specific [project](administrate#projects).
**Roles** can be consumed by the [clients](administrate#clients) which exist within a specific [project](administrate#projects).
For more information about how **roles** can be consumed have a look the the protocol specific information.
For more information about how **roles** can be consumed, have a look the protocol specific information.
- [OpenID Connect / OAuth](integrate#How_to_consume_authorizations_in_your_application_or_service)
@ -22,13 +22,13 @@ Each **role** consist of three fields.
| Display Name | A descriptive text for the purpose of the **Role** | User is the default role provided to each person |
| Group | The group field allows to group certain roles who belong in the same context | User and Admin in the group **default** |
### Grantig Roles
### 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).
#### Grant Roles to Organisations
The possibility to grant **roles** to an [organisation](administrate#Organisations) is intented 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 [org](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.
@ -36,6 +36,6 @@ For example a **service provider** could grant the **roles** user, and manager t
#### Grant Roles to Users
By granting **roles** to [users](administrate#Users), be it [humanes or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) recieves 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 resources from a service.
> Screenshot here

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

@ -9,14 +9,14 @@ Nonetheless we treat them all the same in regard to [roles](administrate#Roles)
#### Human vs. Service Users
The major difference between humane 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 login 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 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”.
> 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 it's own pool of usernames which include human and service [users](administrate#Users).
**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.
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`.

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

@ -4,8 +4,8 @@ title: Policies
### What are policies
Polices are a means of enforcing certain behavior of ZITADEL.
ZITADEL defines a default policy on the system level. However a org. owner can change these aspects within his own org.
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.
Below is a list of available policies
@ -24,7 +24,7 @@ This policy enforces passwords of users within the org. to be compliant.
### 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 there email as username.
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`
> Screenshot here

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

@ -4,7 +4,7 @@ title: Identity Providers
### What are Identity Providers
Identity providers or in short idp's are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
Identity providers or in short idps are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
Normally federation uses protocols like [OpenID Connect 1.0](https://openid.net/connect/), [OAuth 2.0](https://oauth.net/2/) and [SAML 2.0](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).
Some examples include:
@ -33,7 +33,7 @@ Some examples include:
### What is Identity Brokering
ZITADEL supports the usage as identity broker, by linking multiple external idp's into one user.
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.
### Manage Identity Providers
@ -54,13 +54,13 @@ SAML 2.0 will follow later on.
> This is a work in progress.
Storage federation is a means of integrating existing identity storage like [LDAP](https://tools.ietf.org/html/rfc4511) and [ADDS](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview).
With this process **ZITADEL** can authenticate users with LDAP Binding and SPNNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
With this process **ZITADEL** can authenticate users with LDAP Binding and SPNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
#### Sync Settings
Here we will document all the different sync options
- Readonly
- Read-only
- Writeback
- just-in-time sync
- scheduled sync

12
site/docs/administrate/90-system.en.md
View File

@ -8,16 +8,16 @@ System describes the root of ZITADEL and includes all other elements like organi
### Default Policies
When ZITADEL is setup for the first time we establish certain default polices for the whole system.
When ZITADEL is set up for the first time we establish certain default policies for the whole system.
> TODO Document default policy settings
### Manage Read Models
Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consist of logonname and the password hash so that the login process can query that data.
Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consists of logonname and the password hash so that the login process can query that data.
All read models are eventual consistent by nature and sometimes an administrator would like to verify they are still up-to date.
In the ZITADEL Console is a section called administration available where the admin can check all read models and there current state.
All read models are eventually consistent by nature and sometimes an administrator would like to verify they are still up-to-date.
In the ZITADEL Console is a section called administration available where the admin can check all read models and their current state.
There is even a possibility to regenerate a read model.
> When a read model is regenerated it might take up some time to be fully operational again
@ -27,7 +27,7 @@ There is even a possibility to regenerate a read model.
### Secret Handling
ZITADEL store secrets always encrypted or hashed in it's storage.
ZITADEL stores secrets always encrypted or hashed in it's storage.
Whenever feasible we try to utilize public / private key mechanics to handle secrets.
**Encryption**
@ -44,7 +44,7 @@ These keys are randomly generated within ZITADEL and are rotated on a regular ba
> Signing keys are stored with AES256 encryption
**TLS**
Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handlings is out of context in this regard.
Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handling are out of context in this regard.
However ZITADEL can use TLS keys at runtime level.
> TODO Document TLS config

6
site/docs/develop/00-overview.en.md
View File

@ -10,7 +10,7 @@ description: …
---
ZITADEL provides three API's for different use cases. These API's are built with GRPC and then generate a REST service.
Each services proto definition is located in the source control on GitHub.
Each service's proto definition is located in the source control on GitHub.
As we generate the REST services and Swagger file out of the proto definition we recommend that you rely on the proto file.
We annotate the corresponding REST methods on each possible call as well as the AuthN and AuthZ requirements.
@ -28,10 +28,10 @@ See below for an example with the call **GetMyUser**.
};
}
```
---
As you can see the `GetMyUser` function is also available as REST service under the path `/users/me`.
As you can see the `GetMyUser` function is also available as a REST service under the path `/users/me`.
In the table below you can see the URI of those calls.
| Service | URI |

2
site/docs/develop/02-management.en.md
View File

@ -5,7 +5,7 @@ description: …
### Management
The management API is as the name states the interface where systems can mutate IAM objects like, organisations, projects, clients, user and so on if they have the necessary access rights.
The management API is as the name states the interface where systems can mutate IAM objects like, organisations, projects, clients, users and so on if they have the necessary access rights.
| Service | URI |
|:--------|:----------------------------------------------------------------------------------------------------------------------------------------------------|

4
site/docs/documentation/01-priciples.en.md
View File

@ -15,9 +15,9 @@ title: Principles
- Embrace automation
- Design API first
- Optimize all components for day-two operations
- Use only opensource projects with permissive licenses
- Use only open source projects with permissive licenses
- Don't roll your own crypto algorithm
- Embrace (industry) standard as much as possible
- Make use of platform features
- Be able to run with a CDN and WAF
- Releases utilized sematic versioning and release whenever feasible
- Releases utilized semantic versioning and release whenever feasible

8
site/docs/documentation/03-openidoauth.en.md
View File

@ -17,8 +17,8 @@ Under normal circumstances **ZITADEL** need four domain names to operate properl
#### OpenID Connect 1.0 Discovery
The OpenID Connect Discovery Endpoint is located with the issuer domain.
For example with [zitadel.ch](https://zitadel.ch) this would be the domain [issuer.zitadel.ch](https://issuer.zitadel.ch). This would give us [https://issuer.zitadel.ch/.well-known/openid-configuration](https://issuer.zitadel.ch/.well-known/openid-configuration).
The OpenID Connect Discovery Endpoint is located within the issuer domain.
For example with [zitadel.ch](zitadel.ch) this would be the domain [issuer.zitadel.ch](issuer.zitadel.ch). This would give us [https://issuer.zitadel.ch/.well-known/openid-configuration](https://issuer.zitadel.ch/.well-known/openid-configuration).
**Link to spec.** [OpenID Connect Discovery 1.0 incorporating errata set 1](https://openid.net/specs/openid-connect-discovery-1_0.html)
@ -65,7 +65,7 @@ In addition to the standard compliant scopes we utilize the following scopes.
| Scope | Description | Example |
|:------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
| urn:zitadel:iam:org:project:role:{rolename} | By using this scope a [client](administrate#clients) can request the claim urn:zitadel:iam:roles:rolename} to be asserted when possible. As an alternative approach you can enable all [roles](administrate#Roles) to be asserted from the [project](administrate#projects) a [client](administrate#clients) belongs to. See details [here](administrate#RBAC_Settings) | urn:zitadel:iam:org:project:role:user |
| urn:zitadel:iam:org:domain:primary:{domainname} | When requesting this scope **ZITADEL** will enforce that the user is member of the selected organisation. If the organisation does not exist a failure is displayed | urn:zitadel:iam:org:domain:primary:acme.ch |
| urn:zitadel:iam:org:domain:primary:{domainname} | When requesting this scope **ZITADEL** will enforce that the user is a member of the selected organisation. If the organisation does not exist a failure is displayed | urn:zitadel:iam:org:domain:primary:acme.ch |
| urn:zitadel:iam:role:{rolename} | | |
### Claims
@ -133,7 +133,7 @@ For a list of supported or unsupported `Grant Types` please have a look at the t
#### Resource Owner Password Credentials
> Due to growing security concern we do not support this grant type. With OAuth 2.1 it looks like this grant will be removed.
> Due to growing security concerns we do not support this grant type. With OAuth 2.1 it looks like this grant will be removed.
**Link to spec.** [OThe OAuth 2.0 Authorization Framework Section 1.3.3](https://tools.ietf.org/html/rfc6749#section-1.3.3)

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

@ -12,7 +12,7 @@ You can either use [ZITADEL.ch](https://zitadel.ch) or deploy a dedicated **ZITA
### Use ZITADEL.ch
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 a email with further instructions.
After accepting the TOS and filling out all the required fields you will receive an email with further instructions.
<div class="zitadel-gallery" itemscope itemtype="http://schema.org/ImageGallery">
<figure itemprop="associatedMedia" itemscope itemtype="http://schema.org/ImageObject">
@ -25,7 +25,7 @@ After accepting the TOS and filling out all the required fields you will receive
#### Verify your domain name (optional)
When you verify your domain you get the benefit that your [organisations](administrate#Organisations) [users](administrate#Users) can use this domain as **preferred loginname**. You find a more detailed explanation [How ZITADEL handles usernames](administrate#How_ZITADEL_handles_usernames).
When you verify your domain you get the benefit that your [organisations](administrate#Organisations) [users](administrate#Users) can use this domain as **preferred logonname**. You find a more detailed explanation [How ZITADEL handles usernames](administrate#How_ZITADEL_handles_usernames).
The verification process is documented [here](administrate#Verify_a_domain_name)