mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-10 16:15: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
@@ -11,7 +11,7 @@ Administrators can [restrict end-users from accessing the management console](/g
|
||||
|
||||
Here's an overview of what the management console enables users to do:
|
||||
|
||||
1. **Default Settings:** [Managers](/concepts/structure/managers) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.
|
||||
1. **Default Settings:** [Administrators](/concepts/structure/administrators) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.
|
||||
|
||||
2. **Resource Management:** The management console allows for the creation, updating, and deletion of essential resources such as organizations, users, projects, and applications. Administrators can efficiently manage these entities to ensure proper access control and governance.
|
||||
|
||||
@@ -23,7 +23,7 @@ Here's an overview of what the management console enables users to do:
|
||||
|
||||
6. **Customization and Branding:** The management console allows organizations to customize the branding and appearance of their ZITADEL instance. This includes uploading custom logos, selecting color schemes, and applying other visual customizations to align the interface with the organization's branding guidelines.
|
||||
|
||||
7. **Manager Assignment:** Administrators can assign ZITADEL [managers](/concepts/structure/managers) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.
|
||||
7. **Administrator Assignment:** Administrators can assign ZITADEL [administrators](/concepts/structure/administrators) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.
|
||||
|
||||
Overall, the ZITADEL management console serves as a comprehensive tool for administrators to configure, manage, and monitor identity and access management within their organization, providing the necessary controls to ensure security, compliance, and efficient administration of resources.
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ For example some organizations might use their EntraID, some other want to login
|
||||
Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.
|
||||
|
||||
[Domain discovery](/guides/solution-scenarios/domain-discovery) ensures that users are redirected to their external identity provider based on their email-address or username.
|
||||
[Managers](../structure/managers) can configure organization domains that are used for domain-based redirection to an external IdP.
|
||||
[Administrators](../structure/administrators) can configure organization domains that are used for domain-based redirection to an external IdP.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -9,12 +9,12 @@ For these tasks we either provide a user interface, or the tasks can be initiate
|
||||
It is important to understand that, depending on your use case, there will exist different user-types that want to perform different actions:
|
||||
|
||||
- `Users` are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators, etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.
|
||||
- `Managers` are users with a [special administrator role](../../guides/manage/console/managers) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
|
||||
- `Administrators` are users with a [special administrator role](../../guides/manage/console/administrators) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
|
||||
|
||||
All self-service interfaces are available in different [languages](/guides/manage/customize/texts#internationalization-i-18-n).
|
||||
|
||||
<Callout>
|
||||
ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Managers](#managers).
|
||||
ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Administrators](#administrators).
|
||||
</Callout>
|
||||
|
||||
## Registration
|
||||
@@ -126,24 +126,24 @@ Users can create a connection between a [local user account](#local-account) and
|
||||
The user can log in with any of the linked accounts.
|
||||
[Linking of external accounts](#account-linking) is done during the login process.
|
||||
|
||||
## Managers
|
||||
## Administrators
|
||||
|
||||
It is important to note that a `Manager` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
|
||||
It is important to note that an `Administrator` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
|
||||
|
||||
Thus, we will explain service for two of the most common scenarios in ZITADEL:
|
||||
|
||||
- `Managers in isolation`: Granting administrative permissions within a single organization context.
|
||||
- `Managers in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other
|
||||
- `Administrators in isolation`: Granting administrative permissions within a single organization context.
|
||||
- `Administrators in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other
|
||||
|
||||
A list of [Administrator Roles](../../guides/manage/console/managers#roles) is available with a description of permissions.
|
||||
Managers can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
|
||||
A list of [Administrator Roles](../../guides/manage/console/administrators#roles) is available with a description of permissions.
|
||||
Administrators can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
|
||||
|
||||
### Managers in isolation
|
||||
### Administrators in isolation
|
||||
|
||||
A user with Administrator roles `IAM_OWNER` or `ORG_OWNER` might want to assign other users from their organization elevated permissions to handle certain aspects of the IAM tasks.
|
||||
This could be permission to assign authorizations within this isolated organization (`ORG_USER_MANAGER`) or handling setup of projects and applications (`PROJECT_OWNER`).
|
||||
|
||||
### Managers in delegation
|
||||
### Administrators in delegation
|
||||
|
||||
In a setup like described in the [B2B Scenario](/guides/solution-scenarios/b2b), there exists an organization of the project owner and a customer organization.
|
||||
The project is granted to the customer organization, such that the customer can access the project and assign authorization to their users.
|
||||
@@ -151,6 +151,6 @@ The project is granted to the customer organization, such that the customer can
|
||||
Given such as set up the owner might want to give one administrative user of the customer organization the role `ORG_OWNER`.
|
||||
Equipped with this Administrator Role, the user can perform actions like configuring their own SSO/Identity Provider, set security policy for their organization, customize branding, or assign project or Administrator roles to other users.
|
||||
|
||||
An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#managers-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
|
||||
An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#administrators-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
|
||||
With ZITADEL there is no need to replicate all settings and projects across organizations.
|
||||
Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Managers of that organization to allow for self-service in a multi-tenancy scenario.
|
||||
Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Administrators of that organization to allow for self-service in a multi-tenancy scenario.
|
||||
|
||||
@@ -16,5 +16,5 @@ import { FileText, Folder, Link as LinkIcon } from 'lucide-react';
|
||||
<Card title="Projects Overview" href="/guides/manage/console/projects-overview" icon={<FileText />} />
|
||||
<Card title="Applications Overview" href="/guides/manage/console/applications-overview" icon={<FileText />} />
|
||||
<Card title="Users Overview" href="/guides/manage/console/users-overview" icon={<FileText />} />
|
||||
<Card title="Managers" href="/concepts/structure/managers" icon={<FileText />} />
|
||||
<Card title="Administrators" href="/concepts/structure/administrators" icon={<FileText />} />
|
||||
</Cards>
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
Administrators are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
|
||||
|
||||
Administrator permissions can be assigned to different levels in ZITADEL:
|
||||
|
||||
- **IAM Administrators**: This is the highest level. Users with IAM Administrator roles are able to manage the whole [Instance](/concepts/structure/instance).
|
||||
- **Organization Administrators**: Administrators at the Organization level are able to view or manage everything, according to their permissions, within the granted [Organization](/guides/manage/console/organizations-overview).
|
||||
- **Project Administrators**: In this level the user is able to manage a [project](/guides/manage/console/projects-overview).
|
||||
- **Project Grant Administrators**: The project grant administrator manages [projects granted](/concepts/structure/granted_projects) by another organization.
|
||||
|
||||
The scope of the administrators is restricted based on their level.
|
||||
Which means that an administrator, assigned to one organization, will have access only to the resources and configurations of that organization.
|
||||
Only the Administrators on the instance level can view resources, such as users, across all organizations.
|
||||
@@ -1,12 +0,0 @@
|
||||
Managers are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
|
||||
|
||||
Manager permissions can be assigned to different levels in ZITADEL:
|
||||
|
||||
- **IAM Managers**: This is the highest level. Users with IAM Administrator roles are able to manage the whole [Instance](/concepts/structure/instance).
|
||||
- **Org Managers**: Managers in the Organization Level are able to view or manage everything, according to their permissions, within the granted [Organization](/guides/manage/console/organizations-overview).
|
||||
- **Project Mangers**: In this level the user is able to manage a [project](/guides/manage/console/projects-overview).
|
||||
- **Project Grant Manager**: The project grant manager is for [granted projects](/concepts/structure/granted_projects) by another organization.
|
||||
|
||||
The scope of the managers is restricted based on their level.
|
||||
Which means that a Manager, assigned to one organization, will have access only to the resources and configurations of that organization.
|
||||
Only the Managers on the instance level can view resources, such as users, across all organizations.
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Administrators
|
||||
sidebar_label: Administrators
|
||||
---
|
||||
|
||||
import AdministratorDescription from "./_administrator_description.mdx";
|
||||
|
||||
<AdministratorDescription components={props.components} name="AdministratorDescription" />
|
||||
|
||||
Notes:
|
||||
|
||||
- Read our [guide on Administrators](../../guides/manage/console/administrators) to learn more about the role concept and how to use Administrator roles in ZITADEL.
|
||||
- [API reference](/apis/resources/mgmt/management-service-list-org-member-roles) for Administrators on the organization level
|
||||
@@ -20,7 +20,7 @@ ZITADEL supports the following application types:
|
||||
Ensure the configuration of application settings is limited to authorized users only.
|
||||
|
||||
You can configure applications in the [management console](/guides/manage/console/organizations-overview).
|
||||
Read about our [managers](/concepts/structure/managers) and [granted projects](/concepts/structure/granted_projects)
|
||||
Read about our [administrators](/concepts/structure/administrators) and [granted projects](/concepts/structure/granted_projects)
|
||||
concepts.
|
||||
|
||||
## References
|
||||
|
||||
@@ -8,6 +8,6 @@ title: Structure
|
||||
<Card href="/concepts/structure/projects" title="Projects" />
|
||||
<Card href="/concepts/structure/applications" title="Applications" />
|
||||
<Card href="/concepts/structure/users" title="Users" />
|
||||
<Card href="/concepts/structure/managers" title="Managers" />
|
||||
<Card href="/concepts/structure/administrators" title="Administrators" />
|
||||
<Card href="/concepts/structure/policies" title="Policies" />
|
||||
</Cards>
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
---
|
||||
title: Managers
|
||||
sidebar_label: Managers
|
||||
---
|
||||
|
||||
import ManagerDescription from "./_manager_description.mdx";
|
||||
|
||||
<ManagerDescription components={props.components} name="ManagerDescription" />
|
||||
|
||||
Notes:
|
||||
|
||||
- Read our [guide on Managers](../../guides/manage/console/managers) to learn more about the role concept and how to use Administrator roles in ZITADEL.
|
||||
- [API reference](/apis/resources/mgmt/management-service-list-org-member-roles) for Managers on the organization level
|
||||
@@ -25,9 +25,9 @@ The main difference between users and service accounts is the type of credential
|
||||
|
||||
Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.
|
||||
|
||||
### Managers
|
||||
### Administrators
|
||||
|
||||
Any user or service account can be given a [Manager](/concepts/structure/managers) role.
|
||||
Any user or service account can be assigned an [Administrator](/concepts/structure/administrators) role.
|
||||
A user with an administrator role is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.
|
||||
|
||||
### Federated users
|
||||
@@ -59,7 +59,7 @@ Consider this general recommendation as a starting point:
|
||||
- Create one organization ("default organization") for your own company
|
||||
- Configure projects and applications in the default organization
|
||||
- Structure users in organizations based on common domains that are self-managed (eg, company)
|
||||
- Grant your projects to the organizations, allow Managers to give granted roles to their users
|
||||
- Grant your projects to the organizations, allow Administrators to give granted roles to their users
|
||||
|
||||
You might want to adjust this general setup based on your [scenario](/guides/solution-scenarios).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user