andwati/zitadel
1
0
Fork 0
mirror of https://github.com/andwati/zitadel.git synced 2026-11-01 20:02:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: replace given and family names with first and last names (#11343)

Browse Source 
# Which Problems Are Solved

Naming inconsistency w.r.t the usage of Given Name / Family Name instead
of First Name / Last Name

# How the Problems Are Solved

* By replacing given and family names with first and last names in UI
and docs (not in the API definitions)
* Updated translations in multiple languages to first and last names
instead of given/family names

# Additional Changes
* Add `internal/**/*.yaml` path to the nx sources input to rebuild the
binary upon changes to these files
* Fix failing unit tests in `user_notifier_legacy_test.go` by updating
`Passwordless` with `Passkey`

# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11308

---------

Co-authored-by: Copilot <[email protected]>
Co-authored-by: Wim Van Laer <[email protected]>
This commit is contained in:
Gayathri Vijayan
2026-01-15 10:29:48 +00:00
committed by GitHub
co-authored by Copilot Wim Van Laer
parent 2797a0bb03
commit be9d2a53eb
44 changed files with 113 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/docs/apis/actions/external-authentication.md
+4 -4
View File
@@ -44,9 +44,9 @@ The first parameter contains the following fields
- `appendMetadata(string, Any)`
The first parameter represents the key and the second a value which will be stored
- `setFirstName(string)`
Sets the given name
Sets the first name
- `setLastName(string)`
Sets the family name
Sets the last name
- `setNickName(string)`
Sets the nickname
- `setDisplayName(string)`
@@ -87,9 +87,9 @@ The trigger is represented by the following Ids in the API: `TRIGGER_TYPE_PRE_CR
- `metadata`
Array of [*metadata*](./objects#metadata-with-value-as-bytes). This function is deprecated, please use `api.v1.user.appendMetadata`
- `setFirstName(string)`
Sets the given name
Sets the first name
- `setLastName(string)`
Sets the family name
Sets the last name
- `setNickName(string)`
Sets the nick name
- `setDisplayName(string)`
docs/docs/apis/openidoauth/claims.md
+2 -2
View File
@@ -57,9 +57,9 @@ Please check below the matrix for an overview where which scope is asserted.
| email_verified | `true` | Boolean if the email was verified by ZITADEL |
| events | `{ "http://schemas.openid.net/event/backchannel-logout": {} }` | Security Events such as Back-Channel Logout |
| exp | `1311281970` | Time the token expires (as unix time) |
| family_name | `Runner` | The subjects family name |
| family_name | `Runner` | Last name of the subject |
| gender | `other` | Gender of the subject |
| given_name | `Road` | Given name of the subject |
| given_name | `Road` | First name of the subject |
| iat | `1311280970` | Time of the token was issued at (as unix time) |
| iss | `$CUSTOM-DOMAIN` | Issuing domain of a token |
| jti | `69234237813329048` | Unique id of the token |
docs/docs/guides/integrate/identity-providers/azure-ad-oidc.mdx
+1 -1
View File
@@ -53,7 +53,7 @@ To allow ZITADEL to get the information from the authenticating user you have to
1. Click on Token configuration in the side menu
2. Click on "+ Add optional claim"
3. Add email, family_name, given_name and preferred_username to the id token
3. Add email, family_name (last name of the user), given_name (first name of the user) and preferred_username to the id token
![Azure Token configuration](/img/guides/azure_token_configuration.png)
docs/docs/guides/integrate/identity-providers/onelogin-saml.mdx
+2 -2
View File
@@ -129,8 +129,8 @@ To provision users correctly in ZITADEL, configure which attributes OneLogin sen
3. Add or edit parameters so that at least the following are sent and **included in the SAML assertion**:
- `email` → mapped to the user’s email address (for example **Email**).
- `firstName` → mapped to the user’s given name (for example **First Name**).
- `lastName` → mapped to the user’s family name (for example **Last Name**).
- `firstName` → mapped to the user’s first name (for example **First Name**).
- `lastName` → mapped to the user’s last name (for example **Last Name**).
4. Ensure the **NameID** is set to a unique identifier (commonly the user’s email address), if your OneLogin connector requires it.
5. Save your changes.
docs/docs/guides/integrate/identity-providers/pingfederate-saml.mdx
+1 -1
View File
@@ -39,7 +39,7 @@ After the ZITADEL SAML provider exists, we’ll return to PingFederate and finis
2. Make sure **SAML 2.0** Browser SSO is enabled for this connection.
3. Proceed to **Assertion Creation**:
- Keep the default **NameID** attribute.
- Add additional attributes you want to send to ZITADEL (you need at least `email`, `given_name`, `family_name`, and you can send optional attributes like `display_name`).
- Add additional attributes you want to send to ZITADEL (you need at least `email`, `given_name` (first name of the user), `family_name` (last name of the user), and you can send optional attributes like `display_name`).
4. In **Attribute Mapping**, map the contract attributes to your directory/user store fields.
### Export PingFederate IdP metadata
docs/docs/guides/integrate/onboarding/end-users.mdx
+1 -1
View File
@@ -87,7 +87,7 @@ urn:zitadel:iam:org:id:{id}
```
If the user chooses to register a local account, the register form will be shown.
All the mandatory fields like given name, family name, e-mail and password have to be filled.
All the mandatory fields like first name, last name, e-mail and password have to be filled.
You can only setup authentication with the built-in form.
<img
docs/docs/guides/manage/customize/user-schema.md
+16 -17
View File
@@ -10,8 +10,8 @@ By defining multiple schemas, you can even differentiate between different perso
and restrictions, resp. requirements for them to authenticate.
For example, you could have separate schemas for your employees and your customers. While you might want to make sure that
certain data like given name and family name are required for employees, they might be optional for the latter.
Or you might want to disable username password authentication for your admins and only allow phishing resistant methods like passkeys,
certain data, such as the first name and the last name, are required for employees, they might be optional for the latter.
Or you might want to disable username-password authentication for your admins and only allow phishing-resistant methods (e.g., passkeys),
but still allow it for your customers.
:::info
@@ -23,11 +23,11 @@ Do not use it for production yet. To test it out, you need to enable the `UserSc
## Create your first schema
Let's create the first very simple schema `user`, which defines a `givenName` and `familyName` for a user and allows them to
authenticate with username and password.
Let's create your first schema, `user`, which defines a `givenName` (first name) and `familyName` (last name) for a user and allows them to
authenticate with their username and password.
We can do so by calling the [create user schema endpoint](/docs/apis/resources/user_schema_service_v3/user-schema-service-create-user-schema)
with the following data. Make sure to provide an access_token with an IAM_OWNER role.
with the following data. Make sure to provide an `access_token` with an `IAM_OWNER` role.
```bash
curl -X POST "https://$CUSTOM-DOMAIN/v3alpha/user_schemas" \
@@ -67,18 +67,18 @@ This will return something similar to:
}
```
So you successfully create a schema and could use that to manage your users based on that.
But let's first checkout some possibilities ZITADEL offers.
You have now successfully created a schema, which can be used to manage your users.
But let's first check out some possibilities ZITADEL offers.
## Assign Permissions
In the first step we've created a very simple `user` schema with only `givenName` and `familyName`.
This allows any user with the permission to edit the user's data to change these values.
Let's now update the schema and add some more properties and restrict who's able to retrieve and change data.
In the first step we created a very simple `user` schema with only `givenName` (first name) and `familyName` (last name).
This allows any user with permissions to edit the user's data to change these values.
Let's now update the schema to add some more properties and restrict who's able to retrieve and change data.
By setting `urn:zitadel:schema:permission` to fields, we can define the permissions for that field of different user roles / context.
For example by adding it to the `givenName` and `familyName` we can keep the state from before, where any `owner` (e.g. ORG_OWNER)
For example, by adding it to the `givenName` and `familyName` we can keep the state from before, where any `owner` (e.g. ORG_OWNER)
as well as the user themselves (`self`) are allowed to read (`r`) and write (`w`) the data.
Let's now assume our service provides some profile information of the user on a dedicated page.
@@ -136,9 +136,9 @@ curl -X PUT "https://$CUSTOM-DOMAIN/v3alpha/user_schemas/$SCHEMA_ID" \
## Retrieve the Existing Schemas
To check the state of existing schemas you can simply [list them](/apis/resources/user_schema_service_v3/user-schema-service-list-user-schemas).
To check the state of existing schemas, you can simply [list them](/apis/resources/user_schema_service_v3/user-schema-service-list-user-schemas).
In this case we will query for the one with state `active`. Check out the api documentation for detailed information on possible filters.
The API also allows to retrieve a single [schema by ID](/apis/resources/user_schema_service_v3/user-schema-service-get-user-schema-by-id).
The API also allows retrieving a single [schema by ID](/apis/resources/user_schema_service_v3/user-schema-service-get-user-schema-by-id).
```bash
curl -X POST "https://$CUSTOM-DOMAIN/v3alpha/user_schemas/search" \
@@ -162,7 +162,7 @@ curl -X POST "https://$CUSTOM-DOMAIN/v3alpha/user_schemas/search" \
}'
```
If you've followed this guide, it should list you a singe schema:
If you've followed this guide, it should list you a single schema:
```json
{
@@ -226,6 +226,5 @@ If you've followed this guide, it should list you a singe schema:
### Revision
Note the `revision` property, which is currently `2`. Each update to the `schema`-property will increase
it by `1`. The revision will later be reflected on the managed users to state based on which revision of the schema
they were last updated on.
Note the `revision` property, which is currently `2`. Each update to the `schema`-property will increment
it by `1`. This revision number will be stored on managed users to indicate which schema version was used for their last update.
docs/docs/legal/_piid-table.mdx
+1 -1
View File
@@ -8,7 +8,7 @@
<td><strong>Basic data</strong></td>
<td>
<ul>
<li>Family and given name</li>
<li>First and last names</li>
<li>Email addresses</li>
<li>User name</li>
</ul>
docs/static/img/guides/console/invitehuman.png
Vendored
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 48 KiB

After

Width:  |  Height:  |  Size: 121 KiB