# People and administrators (https://docs.idra.zone/docs/admin/users)

Add and import people, manage their lifecycle, custom attributes, identity providers and admin roles.

## Add people

**Directory → People → Add person**: First name, Last name, Email (the username, which can't be changed here; an inbound SCIM source can change it), Groups, and **Activate now**. With Activate now on, the person gets an activation email (the link lasts 7 days). With it off, they're created **Staged** and you activate them later.

### Import a CSV

**Directory → People → Import** walks through four steps: upload, map columns, preview, options. Nothing is written until you start the import.

```csv
email,firstName,lastName,department,groups
ann@example.com,Ann,Lee,Engineering,Engineering;VPN users
bob@example.com,Bob,Ng,Sales,Sales
```

- `email` is required. Other columns: `firstName`, `lastName`, any [Profile Editor](#profile-editor) attribute, and `groups` (names separated by `;`).
- Common header names are mapped automatically (`mail`, `username`, `givenname`, `surname`…). **Sample CSV** downloads a template.
- Up to 10,000 rows and 5 MB.
- Options: **Update existing people** (empty cells keep current values), **Send activation emails**, and add everyone in the file to extra groups.
- Rows that fail can be downloaded as a CSV.

## Lifecycle

| Status | Meaning |
| --- | --- |
| **Staged** | Created, not activated. |
| **Pending user action** | Activation email sent, password not set yet. |
| **Active** | Can sign in. |
| **Password reset** | A reset was sent; the person must set a new password. |
| **Suspended** | Can't sign in; everything else is kept. |
| **Deactivated** | Sessions ended, OAuth tokens revoked, accounts in provisioned apps deactivated. |

Badges also show **Locked out** and **Password expired**.

On a person's page: **Activate**, **Reactivate** and **Unsuspend** are buttons; **More actions** has Suspend, Deactivate, Reset password, Reset authenticators, Clear sessions, Unlock, Delete (deactivated people only) and **Login as user**.

- **Reset authenticators** removes their authenticator app and passkeys (per-method resets are on the Authenticators tab).
- **Clear sessions** signs them out everywhere and revokes OAuth tokens.
- **Login as user** (impersonation) is for Super Administrators, on active non-admin people.
- You can't deactivate, suspend or delete yourself, or the last Super Administrator. Only Super Administrators can act on other admins.

The person's tabs: Profile, Groups, Applications, Authenticators, Sessions & devices, Risk, Admin roles and System Log.

## Profile Editor

**Directory → Profile Editor** defines the profile attributes. Built in: `firstName`, `lastName`, `title`, `department`, `manager`, `employeeNumber`, `mobilePhone`, `city`, `countryCode`. Add your own with a display name, a variable name, a data type (String, Number, Boolean, Date, Enum) and whether it's required. Attributes feed group rules, SAML attribute statements, SCIM mappings and gateway headers as `profile.<variable name>`.

## Identity providers

**Security → Identity Providers → Add identity provider** lets people sign in with another IdP (Microsoft Entra ID, Google, Okta…), routed by email domain on the sign-in page.

- Common: **Name**, **Provider ID** (e.g. `entra`), **Email domains** (a domain belongs to one IdP).
- **OpenID Connect:** Issuer URL, Client ID, Client secret, optional Discovery URL, Scopes (default `openid email profile`). Redirect URI to register at the IdP: `<BASE_URL>/api/auth/sso/callback/<providerId>`.
- **SAML 2.0:** IdP metadata XML, or SSO URL, entity ID and signing certificate. Give the IdP the ACS URL `<BASE_URL>/api/auth/sso/saml2/sp/acs/<providerId>` and the SP metadata `<BASE_URL>/api/auth/sso/saml2/sp/metadata?providerId=<providerId>`.
- **Create people on first sign-in (just-in-time provisioning)** is on by default. Turning it off is enforced for SP-initiated sign-ins.

Deleting a provider unlinks accounts but keeps the people.

## Administrators

**Security → Administrators → Add administrator**: choose a person and a role. A person can hold several roles. Only Super Administrators can grant or revoke roles.

| Role | Can |
| --- | --- |
| **Super Administrator** | Everything: policies, settings, event hooks, API tokens, roles, impersonation. |
| **Organization Administrator** | Manage people, sessions, groups, apps, privileged access and partners; read policies, settings, posture and reports. |
| **Application Administrator** | Manage apps; read people, groups and reports. |
| **Help Desk Administrator** | Read people, groups, apps and reports; suspend, unsuspend, unlock, reset passwords and authenticators, revoke sessions. |
| **Read-only Administrator** | Read everything. |

Administrators always need MFA: the console refuses sessions that haven't completed a second factor, whatever the policies say.

## Export and erase a person

**Settings → Privacy**, super administrators only. Find someone by exact email or ID, including people already deleted.

**Export** downloads a JSON file: their account, groups, app assignments, authenticators (without secrets), sessions, devices, risk events, access requests, and the System Log events that mention them. Review it before sending it on, because those events can name the admins who acted on them. The export is logged as `privacy.person.export`.

**Erase** asks you to type their email. A person with an account must be deactivated first, and the erase deletes the account. Then it removes from the retained System Log:

- their name and email, wherever they appear in an event, including an impersonation note and the access-request copies made when an account is deleted
- the IP, location and browser of events they caused, and of failed sign-ins against them with no known actor
- what they wrote in their access requests

It also removes queued jobs that mention them, and recovery attempts on their address. It records `privacy.person.erase` with the admin and the person's ID, and no name, email or IP of theirs. It can't be undone.

What stays, and why:

- **The events themselves**, with types, times, outcomes and the person's opaque ID, because the audit trail must still show what happened. With the account gone, nothing in IdRa links that ID to a person.
- **The IP of an admin acting on them**, which is that admin's own audit record.
- **Other tables that still mention them.** The erase reports them by table and column in its result and its event, such as a connector's copy of a vendor's directory, which the next sync replaces, or a people import's error list. Handle these by hand if the report lists any.
- **Copies outside this database:** event hook and log stream receivers, sent email, and database backups until they age out. A restore from an older backup brings the person back, so keep their ID and erase them again.