mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-14 18:05:12 +00:00
chore: rename manager/member to administrator (#11542)
# Which Problems Are Solved As part of the naming consistency initiative, the terms `Manager`, `Member` and other similar terms that are used in the context of an administrator are replaced by `Administrator` in the UI and documentation. # How the Problems Are Solved By replacing the following terms with Administrator / Administrator Roles in docs, Console UI, and guides. - Manager - Add Manager - Add a Manager - Administrator (used as a person type) - Membership - Member grants # Additional Changes minor grammatical edits in the docs # Additional Context - Closes https://github.com/zitadel/zitadel/issues/11291 --------- Co-authored-by: Marco A. <[email protected]>
This commit is contained in:
Gayathri Vijayan
co-authored by
Marco A.
Marco A.
parent
319c466476
commit
cc7a6145f1
@@ -7,7 +7,7 @@ This section of guides shows you how to migrate from your current auth system to
|
||||
The individual guides in this section should give you an overview of things to consider before you start the migration.
|
||||
|
||||
When moving from a previous auth solution to ZITADEL, it is important to note that some decisions and features are unique to ZITADEL.
|
||||
Without duplicating too much content here are some important features and patterns to consider in terms of solution architecture.
|
||||
Without duplicating too much content, here are some important features and patterns to consider in terms of solution architecture.
|
||||
You can read more about the basic structure and important concepts of ZITADEL in our [concepts section](/concepts).
|
||||
|
||||
## Multi-tenancy architecture
|
||||
@@ -15,18 +15,18 @@ You can read more about the basic structure and important concepts of ZITADEL in
|
||||
Multi-tenancy in ZITADEL can be achieved through either [Instances](/concepts/structure/instance) or [Organizations](/concepts/structure/instance) or [Organizations](/guides/manage/console/organizations-overview).
|
||||
Where instances represent isolated ZITADEL instances, Organizations provide a more permeable approach to multi-tenancy.
|
||||
|
||||
In most cases, when you want to achieve multi-tenancy, you use Organizations. Each organization can have their own set of Settings (eg, Security Policies, IDPs, Branding), Managers, and Users.
|
||||
In most cases, when you want to achieve multi-tenancy, you use Organizations. Each organization can have their own set of Settings (eg, Security Policies, IDPs, Branding), Administrators, and Users.
|
||||
Please also consult our guide on [Solution Scenarios](/guides/solution-scenarios) for B2C and B2B for more details.
|
||||
|
||||
## Delegated access management
|
||||
|
||||
Some solutions, that offer multi-tenancy, require you to copy applications and settings to each tenant and manage changes individually.
|
||||
Some solutions that offer multi-tenancy require you to copy applications and settings to each tenant and manage changes individually.
|
||||
ZITADEL works differently by using [Granted Projects](/concepts/structure/granted_projects).
|
||||
|
||||
Projects can be granted to [Organization](/guides/manage/console/organizations-overview#project-grants) or even to individual users.
|
||||
You can think of it as a logical link to a Project, which can be used by the receiving Organization or User as if it was their own project, except privileges to modify the Project itself.
|
||||
|
||||
Delegated access management is a great way of keeping the management overhead low and enabling [self-service](/concepts/features/selfservice#managers-in-delegation) for Organizations to manage their own Settings and Authorizations.
|
||||
Delegated access management is a great way of keeping the administration overhead low and enabling [self-service](/concepts/features/selfservice#administrators-in-delegation) for Organizations to manage their own Settings and Authorizations.
|
||||
|
||||
## Actions
|
||||
|
||||
@@ -35,16 +35,16 @@ ZITADEL [Actions](/guides/manage/console/actions-overview) is the key feature to
|
||||
You define custom code that should be run on a specific Trigger.
|
||||
A trigger could be the creation of a new user, getting profile information about a user, or a login attempt.
|
||||
|
||||
With the [HTTP module](/apis/actions/modules) you can even make calls to third party systems for example to receive additional user information from a backend system, or triggering a workflow in other systems (Webhook).
|
||||
With the [HTTP module](/apis/actions/modules) you can even make calls to third party systems, for example, to receive additional user information from a backend system, or triggering a workflow in other systems (Webhook).
|
||||
|
||||
You can also create custom claims or manipulate tokens and information on the userinfo endpoint by using the [Complement Token Flow](/apis/actions/complement-token).
|
||||
This might be required, if an application expects roles/permissions in a certain format or additional attributes (eg, a backend user-id) as claims.
|
||||
This might be required if an application expects roles/permissions in a certain format or additional attributes (eg, a backend user-id) as claims.
|
||||
|
||||
## Metadata
|
||||
|
||||
You can store arbitrary key-value pairs of data on objects such as Users or Organizations.
|
||||
Metadata could link a user to a specific backend user-id or represent an "organizational unit" for your business logic.
|
||||
Metadata can be access directly with the correct [scopes](/apis/openidoauth/scopes#reserved-scopes) or transformed to custom claims (see above).
|
||||
Metadata can be accessed directly with the correct [scopes](/apis/openidoauth/scopes#reserved-scopes) or transformed to custom claims (see above).
|
||||
|
||||
## Migrating resources
|
||||
|
||||
@@ -79,7 +79,7 @@ For all other cases, we recommend that the **legacy system orchestrates the migr
|
||||
|
||||
In this case the migration can also be done as an import job or also allowing to create user session in both the legacy auth solution and ZITADEL in parallel with identity brokering:
|
||||
|
||||
- Setup ZITADEL to use your legacy system as external identity provider (note: you can also use JWT-IDP, if you only have a token).
|
||||
- Set up ZITADEL to use your legacy system as an external identity provider (note: you can also use JWT-IDP, if you only have a token).
|
||||
- Configure your app to use ZITADEL, which will redirect users automatically to the external identity provider to login.
|
||||
- A session will be created both on the legacy system and ZITADEL
|
||||
- If a user does not exist already in ZITADEL you can auto-register new users and use an Action to pull additional information (eg, Secrets) from your legacy system. Note: ZITADEL links external identity information to users, meaning you can have users use both a password and external identity providers to login with the same user.
|
||||
- If a user does not exist already in ZITADEL, you can auto-register new users and use an Action to pull additional information (eg, Secrets) from your legacy system. Note: ZITADEL links external identity information to users, meaning you can have users use both a password and external identity providers to login with the same user.
|
||||
|
||||
@@ -38,7 +38,7 @@ You need a PAT from a service user with instance Owner permissions in both the s
|
||||
2. Create a service user "import_user" with Access Token Type "Bearer"
|
||||
3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
|
||||
4. Go to the Default settings
|
||||
5. Add the import_user as [manager](/guides/manage/console/managers) with the role "instance Owner"
|
||||
5. Add the import_user as [manager](/guides/manage/console/administrators) with the role "instance Owner"
|
||||
|
||||
Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domain as `ZITADEL_EXPORT_DOMAIN` to run the following scripts.
|
||||
|
||||
@@ -48,7 +48,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai
|
||||
2. Create a service user "export_user" with Access Token Type "Bearer"
|
||||
3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
|
||||
4. Go to the Default settings
|
||||
5. Add the export_user as [manager](/guides/manage/console/managers) with the role "instance Owner"
|
||||
5. Add the export_user as [manager](/guides/manage/console/administrators) with the role "instance Owner"
|
||||
|
||||
Save the PAT to the environment variable `PAT_IMPORT_TOKEN` and the source domain as `ZITADEL_IMPORT_DOMAIN` to run the following scripts.
|
||||
|
||||
@@ -61,7 +61,7 @@ Make sure to delete the created users after you are done with the migration.
|
||||
|
||||
### Export to file
|
||||
|
||||
To export all necessary data you only have to use one request, as an example:
|
||||
To export all necessary data, you only have to use one request, as an example:
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
@@ -165,7 +165,7 @@ To import the exported data into you new instance, you have to have an already e
|
||||
The used serviceaccount has to have at least the role "Storage Object Viewer" to read objects from GCS
|
||||
</Callout>
|
||||
|
||||
Then as an example you can use one request for the import:
|
||||
Then as an example, you can use one request for the import:
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
|
||||
Reference in New Issue
Block a user