|
1 | 1 | # User attribute inheritance |
2 | 2 |
|
3 | | -Child organizations inherit all user attributes defined in the root organization. This includes both default system attributes in {{ product_name }} and any custom attributes created in the root organization. |
| 3 | +In {{product_name}}, child organizations inherit user attributes, user store mappings, and dialects from the root organization, ensuring consistency across the organization hierarchy. |
4 | 4 |
|
5 | | -## User attributes in the local attribute dialect |
| 5 | +## How it works |
6 | 6 |
|
7 | | -Child organizations can only update the attribute configurations that relate to secondary user stores, since each organization defines its own secondary user stores and doesn't share them with others. |
| 7 | +This section explains the inheritance mechanism for attributes, user store mappings, and dialects across organizations. |
8 | 8 |
|
9 | | -You can find these configurations in the **Attribute Mappings** tab of an attribute. |
| 9 | +### User attributes |
10 | 10 |
|
11 | | -### Mapped attributes |
| 11 | +- Child organizations inherit both the system-defined and custom attributes from the root organization. |
12 | 12 |
|
13 | | -{% if product_name == "Asgardeo" %} |
| 13 | +- Only the root organization can create custom attributes. |
14 | 14 |
|
15 | | -You can edit mappings related to user stores ( **MY USER STORE** in this example) independently for each organization. |
| 15 | +Organization administrators can access inherited user attributes from the {{product_name}} Console under **User Attributes & Stores** > **User Attributes**. |
16 | 16 |
|
17 | | -{: width="700" style="display: block; margin: 0;"} |
| 17 | +### User store mappings |
18 | 18 |
|
19 | | -{% else %} |
| 19 | +Each user store in an organization maintains mappings for user attributes. Inheritance of user store mappings works in the following way. |
20 | 20 |
|
21 | | -You can edit the **PRIMARY** user store mappings shown below only in the root organization, which manages the primary user store shared across organizations. |
| 21 | +{% if product_name == "WSO2 Identity Server" %} |
| 22 | +- **Primary user store** |
22 | 23 |
|
23 | | -However, you can edit mappings related to secondary user stores (**MY USER STORE** in this example) independently for each organization. |
| 24 | + - Only the root organization can edit the user store mappings for the primary user store. |
24 | 25 |
|
25 | | -{: width="700" style="display: block; margin: 0;"} |
| 26 | + - Child organizations inherit primary user store mappings from the root organization. |
26 | 27 |
|
27 | | -{% endif %} |
| 28 | +- **Secondary user stores** |
| 29 | + |
| 30 | + - Child organizations can onboard their own secondary user stores. |
| 31 | + |
| 32 | + - Child organizations have full control over user store mappings for secondary user stores, including: |
| 33 | + |
| 34 | + - Editing mappings for user attributes inherited by the root organization. |
| 35 | + |
| 36 | + - Whether to enable multi-valued user attributes (e.g. emailAddresses) for the secondary user stores. This option is only available for supported attributes. |
| 37 | + |
| 38 | + Organization administrators can access user store mappings from the {{product_name}} Console by selecting an attribute from **User Attributes & Stores** > **User Attributes** and going to its **Attribute Mappings** tab. |
| 39 | + |
| 40 | + The following diagram illustrates the attribute mapping section for the multi-valued `emailAddresses` attribute. |
| 41 | + |
| 42 | + {: width="700" style="display: block; margin: 0;"} |
| 43 | + |
| 44 | + - Organizations can't edit the attribute mapping or disable it for the primary user store (**PRIMARY**). |
28 | 45 |
|
29 | | -### Enabling attributes for a user store |
| 46 | + - Child organizations can edit attribute mappings for secondary user stores (**MY USER STORE**). |
30 | 47 |
|
31 | | -For certain multi-valued attributes, such as **Email Addresses**, organizations can configure whether the attribute should be enabled for a specific user store as seen in the above image. For secondary user stores, you can independently manage this setting within each organization. |
32 | 48 |
|
33 | | -### Configuring other properties of attributes |
| 49 | + {% else %} |
34 | 50 |
|
35 | | -All other configurations are directly inherited from root organizations. Therefore, you must set them at the root organization level. |
| 51 | + - Child organizations can onboard their own user stores. |
36 | 52 |
|
37 | | -To learn how to configure user attributes in the root organization, see the following guides: |
| 53 | + - They have full control over attribute mappings for these user stores, including: |
38 | 54 |
|
39 | | -- [Manage attributes]({{base_path}}/guides/users/attributes/manage-attributes) |
40 | | -- [Configure unique attributes]({{base_path}}/guides/users/attributes/configure-unique-attributes) |
| 55 | + - Editing mappings for attributes inherited by the root organization. |
41 | 56 |
|
42 | | -## User attributes in external attribute dialects |
| 57 | + - Whether to enable multi-valued user attributes (e.g. emailAddresses) for the user stores. This option is only available for supported attributes. |
43 | 58 |
|
44 | | -{% if product_name == "Asgardeo" %} |
| 59 | + Organization administrators can access user store mappings from the {{product_name}} Console by selecting an attribute from **User Attributes & Stores** > **User Attributes** and going to its **Attribute Mappings** tab. |
45 | 60 |
|
46 | | -Child organizations inherit external attribute dialects defined by the system in {{ product_name }} such as SCIM 2.0 and OpenID Connect (OIDC). |
| 61 | + The following diagram illustrates the attribute mapping section for the multi-valued `emailAddresses` attribute. |
47 | 62 |
|
48 | | -{% else %} |
| 63 | + {: width="700" style="display: block; margin: 0;"} |
49 | 64 |
|
50 | | -Child organizations inherit external attribute dialects defined by the system in {{ product_name }} such as SCIM 2.0, OpenID Connect (OIDC) and any other custom attribute dialects. |
| 65 | + Child organizations can manage and disable attributes for user stores (**MY USER STORE**). |
51 | 66 |
|
52 | 67 | {% endif %} |
53 | 68 |
|
54 | | -However, child organizations can't create new attribute dialects or modify those inherited from the root. |
| 69 | +### Attribute dialects |
| 70 | + |
| 71 | +Attribute dialects define the naming and format of user attributes when exchanging data with external systems. |
| 72 | + |
| 73 | +- Child organizations inherit all external attribute dialects defined in the root organization, such as: |
| 74 | + |
| 75 | + - SCIM 2.0 |
| 76 | + |
| 77 | + - OpenID Connect (OIDC) |
| 78 | + |
| 79 | + {% if product_name == "WSO2 Identity Server" %} |
| 80 | + |
| 81 | + - Any custom dialects created at the root organization level |
| 82 | + |
| 83 | + {% endif %} |
| 84 | + |
| 85 | +- Attribute dialects are read-only for child organizations. They can't create new dialects or modify inherited ones. |
| 86 | + |
| 87 | +Organization administrators can view user attribute dialects from the {{product_name}} Console by going to **User Attributes & Stores** > **User Attributes** and selecting the relevant dialect under **Manage Attribute Mappings**. |
55 | 88 |
|
56 | | -To learn how to configure external user attributes in the root organization, see the following guides: |
| 89 | +## Configure user attributes at the root organization |
57 | 90 |
|
58 | | -- [Manage SCIM 2.0 attribute mappings]({{base_path}}/guides/users/attributes/manage-scim2-attribute-mappings) |
59 | | -- [Manage OpenID Connect attribute mappings]({{base_path}}/guides/users/attributes/manage-oidc-attribute-mappings) |
| 91 | +Root organization administrators can create user attributes, user store mappings and dialects at the root organization. Follow the [Manage attributes and mappings]({{base_path}}//users/attributes/) guide to learn more. |
0 commit comments