> ## 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 people 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 page is about administering the Iru console. It is distinct from the end
  users in your [directory](/en/identity/directory/directory-overview), who 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 granted to people directly. Instead, a **role** is a named
bundle of permissions, and you grant a person 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 a person access to the console, 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" icon="user-plus">
    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" icon="user-tag">
    Choose the role that matches what the person needs to do. The role
    determines their permissions across the console.
  </Step>

  <Step title="Review and adjust over time" icon="rotate">
    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 person 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 a person 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 console, 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 people 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>