> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Administrators & roles

> Control who can administer Iru Identity, assign built-in or custom admin roles, and scope each administrator's permissions to what their job needs.

**Administrators** are the team members who can sign in to the Iru dashboard and manage
Iru Identity: your directory, applications, policies, and settings. What each
administrator can do is governed by the **role** assigned to them. You manage
both under **Access** in the Iru dashboard, on the **Administrators** and
**Roles** tabs.

<Note>
  This is about the Iru dashboard, not the end-user app launcher. End
  users in your [directory](/en/identity/directory/directory-overview) sign
  in to reach their assigned apps but do not administer Iru. An administrator is
  a directory user who has also been granted an administrative role.
</Note>

## How access is structured

Permissions are not assigned one at a time. Instead, a **role** is a named
bundle of permissions, and you grant someone access by assigning them a role.
Manage roles once, and every administrator who holds a role inherits its
permissions.

```mermaid theme={null}
flowchart LR
  admin["Administrator<br/>(a directory user)"] -->|"is assigned"| role["Role"]
  role -->|"grants"| perms["Permissions"]
  perms -->|"allow actions in"| console["The Iru dashboard"]
```

## Administrators

The **Administrators** tab lists everyone who can administer Iru Identity, with
their name, username, email, status, and assigned role. Add an administrator to
grant them access to the Iru dashboard, and open any administrator to review or
change their role.

<Note>
  One user is designated the tenant's **account owner**, its primary owner. An
  administrator sets the account owner from a user's record.
</Note>

<Steps>
  <Step title="Add an administrator">
    On the **Administrators** tab, choose to add an administrator and enter their
    details, including the email and user principal name they sign in with.
  </Step>

  <Step title="Assign a role">
    Choose the role that matches what they need to do. The role
    determines their permissions across the Iru dashboard.
  </Step>

  <Step title="Review and adjust over time">
    Revisit assignments as responsibilities change, and remove access promptly
    when someone no longer needs it.
  </Step>
</Steps>

<Tip>
  An administrator's **status** follows the same lifecycle as any directory user
  (pending, active, or suspended). Suspending a user blocks their access,
  including their ability to administer Iru, without deleting their record. See
  [Users](/en/identity/directory/users).
</Tip>

## Roles

The **Roles** tab lists every role in your tenant. Each role has a **display
name**, a short **slug** that identifies it, an indication of whether it is a
**default** or **custom** role, and the **permissions** it grants.

### Default roles

Iru Identity ships with a set of built-in **default roles** that cover common
administrative needs. They are marked **Default** in the roles list, and their
permissions are managed by Iru.

| Role                | Intended for                                                                                                                               |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Admin**           | Full administration of Iru Identity. Reserve this for the small number of people who need to manage everything.                            |
| **Standard**        | Day-to-day administration: managing users, their authenticators and devices, and sending invitations, without the most sensitive controls. |
| **Help Desk**       | Front-line support, such as viewing devices and sending invitations, without broad configuration access.                                   |
| **Auditor**         | Read-only visibility for review and oversight, without the ability to make changes.                                                        |
| **Secrets Auditor** | Read-only oversight that extends to sensitive secret material, separated from general auditing.                                            |

<Info>
  Default roles cannot have their permissions edited; they are maintained by
  Iru so their behavior stays consistent. Assign a default role when it fits the
  job, and define a custom role when you need a different combination of
  permissions.
</Info>

### Custom roles

<Note>
  Custom roles are coming soon. Today you assign the built-in default roles above;
  creating your own roles with a tailored set of permissions is on the way.
</Note>

A **custom role** will let you grant exactly the permissions a job needs and
nothing more, with each role's permissions grouped by area and described
individually. Until then, pick the default role that best fits each administrator
and follow the least-privilege guidance below.

### How permissions are expressed

Each permission pairs a **resource** with an **action**, written as
`resource.action`. For example, a permission on the user resource for the view
action lets a role see users. A role's full capability is the set of permissions
it carries.

<Note>
  Some areas of identity data are governed by attribute-level permissions: a
  role that can view users can also see the underlying profile attributes for
  those users. Grant view access deliberately. See
  [Schema](/en/identity/directory/schema).
</Note>

## Least-privilege guidance

Roles exist so you can give each administrator only the access their work requires.
A few practices keep administrative access tight:

<AccordionGroup>
  <Accordion title="Start from the narrowest role that works" icon="compress">
    Assign the most limited role that lets someone do their job, and widen access
    only when a concrete need appears. It is easier to grant a missing permission
    than to notice an unused one.
  </Accordion>

  <Accordion title="Keep the Admin role small" icon="user-lock">
    Full administration is powerful. Limit the number of people with the **Admin**
    role and prefer more focused roles (such as **Help Desk** or **Auditor**)
    for everyone else.
  </Accordion>

  <Accordion title="Use read-only roles for oversight" icon="glasses">
    When someone needs to review activity but not change it, an auditing role
    gives them visibility without the ability to make changes.
  </Accordion>

  <Accordion title="Review assignments regularly" icon="calendar-check">
    Periodically check who holds which role and remove access that is no longer
    needed, especially the most privileged roles. The
    [activity log](/en/identity/administration/activity-log) records role and
    permission changes so you can see how access has shifted over time.
  </Accordion>

  <Accordion title="Protect administrator sign-in" icon="shield-halved">
    Administrators reach sensitive controls, so make sure they are covered by
    strong [authentication policies](/en/identity/authentication/authentication-policies)
    and phishing-resistant [authenticators](/en/identity/authentication/authenticators).
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Activity log" icon="list-timeline" href="/en/identity/administration/activity-log">
    Review who did what in the Iru dashboard, including changes to roles and
    administrator access.
  </Card>

  <Card title="Authentication policies" icon="shield-halved" href="/en/identity/authentication/authentication-policies">
    Set the device-trust conditions enforced when users sign in to your apps.
  </Card>

  <Card title="Users" icon="user" href="/en/identity/directory/users">
    Manage the directory users that administrators are drawn from.
  </Card>

  <Card title="Security and privacy" icon="lock" href="/en/identity/security/security-and-privacy">
    How Iru isolates and protects your tenant and its data.
  </Card>
</CardGroup>