27be460c07
* onboarding components, routing, steps * onboarding component, toc * fix onboarding mixin * header * refactor docs * fix layout * cleanup routing * docs routing * fix conventions * de en routing * docs, guide contents, nav * rem i18n support * fix routing from docs * rollup onwarn changes, preload * update svelte plugin, update rollup config * move docs * revert img style, remove code table * rem de completely * rollup optim, template * angular quickstart, quickstart overview page, update deps * fix link * pack, slug * prefetch binding, hidden links * export log * guards route ch * fix homepage * angular docs * docs * resolve fsh * overview * docs * docs * packages fix race condition * nav, home link * add vue, aspnet * doc optimizations * embed status pal * angular guide * angular guide * dotnet, angular guide * viewbox * typo * block onboarding route for non iam writers * set links from component data * fix: fetch org context in guard, more main cnt (#1192) * change get started guide, fix code blockquotes, typos * flutter guide * h2 spacing * highlight strong * plus * rm start sublinks * add proxy quickstart * regex * prevent outside click, fix project grant write Co-authored-by: Florian Forster <florian@caos.ch> Co-authored-by: Livio Amstutz <livio.a@gmail.com>
5.4 KiB
| title |
|---|
| Users |
What are users
In ZITADEL there are different users. Some belong to dedicated organisations other belong to the global organisation. Some of them are human users others are machines. Nonetheless we treat them all the same in regard to roles management and audit trail.
Human vs. Service Users
The major difference between human vs. machine users is the type of credentials that can be used: With machine 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. Each organisation has its own pool of usernames which includes human and service users.
For example a user with the username road.runner can only exist once in the organisation ACME. ZITADEL will automatically generate a "logonname" for each user 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 instance ZITADEL replace
zitadel.chwith your domain name.
If someone verifies a domain name within the organisation, ZITADEL will generate additional logonames for each user 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, who might have used this combination in the global organisation. Relating to example with
acme.chif a user in the global organisation, let's call himcoyote, usedcoyote@acme.chthis logonname will be replaced withcoyote@randomvalue.tldZITADEL notifies the user about this change
Manage Users
Search Users
Image 1: User List Search
Create Users
Set Password
Screenshot here
Manage Service Users
Screenshot here
Manage User Authorisations
Screenshot here
Manage User ZITADEL Roles
Audit user changes
Screenshot here