> ## 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.

# Key concepts

> Get to know the core objects in Iru Identity, including users, groups, applications, authentication policies, and connections, and how they relate.

Iru Identity revolves around a handful of core objects. Learn what each one is
and how they connect, and the rest of the product will make more sense.

## The big picture

```mermaid theme={null}
flowchart TD
  conn["Federated Authentication"] -->|"sign-in"| dir
  subgraph dir["Directory"]
    users["Users"]
    groups["Groups"]
    attrs["Profile attributes"]
  end
  users --- groups
  attrs --- users
  attrs -. "drive" .-> groups
  groups -->|"assigned to"| apps["Applications"]
  users -->|"assigned to"| apps
  policy["Authentication policies"] -->|"govern sign-in to"| apps
  auth["Authenticators"] -->|"prove identity for"| apps
  apps -->|"accounts provisioned to"| saas["Your SaaS apps"]
  activity["Activity log"] -. "records everything" .- dir
```

## Identity objects

<AccordionGroup>
  <Accordion title="Users" icon="user">
    A **user** is someone in your directory. Each user has a profile made up of
    attributes (name, email, and any custom fields you define). A user moves
    through a lifecycle: they can be **pending** (created but not yet active),
    **active**, or **suspended**. Suspending a user blocks their access without
    deleting their record or history.
  </Accordion>

  <Accordion title="Profile attributes and schema" icon="table-list">
    The **schema** defines the attributes every user profile can hold. Beyond the
    built-in fields, you can add custom attributes with their own type, mark them
    required or unique, give them a fixed list of allowed values, and organize
    them into categories. Attributes are the raw material that policies,
    application mappings, and Auto Groups all build on. See
    [Schema](/en/identity/directory/schema).
  </Accordion>

  <Accordion title="Groups" icon="users">
    A **group** is a collection of users that you assign access to as a unit.
    There are three kinds:

    * **Manual groups**, where you choose the members.
    * **Built-in groups** that exist for every tenant, such as a group that
      contains all users.
    * **Auto Groups**, whose membership is decided by an attribute rule and
      updates itself as profiles change.

    See [Groups](/en/identity/directory/groups) and
    [Auto Groups](/en/identity/directory/auto-groups).
  </Accordion>
</AccordionGroup>

## Access objects

<AccordionGroup>
  <Accordion title="Applications" icon="grip">
    An **application** is something users sign in to through Iru. Iru acts
    as the identity provider for the app using either **SAML** or **OIDC**. Each
    application maps user profile attributes into the assertion or token it sends,
    so the app receives the identity details it expects. Applications are
    versioned: you edit a **draft**, then publish it to make it the **current**
    version, and Iru keeps older versions for reference. An application can be
    **active** or **inactive**.
  </Accordion>

  <Accordion title="Application templates" icon="layer-group">
    A **template** is a ready-made application definition for a known service.
    Creating an app from a template fills in the standard configuration for you,
    so you only supply what is specific to your tenant. See
    [Application templates](/en/identity/applications/application-templates).
  </Accordion>

  <Accordion title="Access assignment" icon="user-check">
    You grant access by **assigning groups** to an application. The full set of
    users who end up with access through those groups is the application's
    **effective users**. See
    [Assigning access](/en/identity/applications/assigning-access).
  </Accordion>

  <Accordion title="Provisioning" icon="arrows-rotate">
    **Provisioning** keeps accounts in sync. **Inbound** provisioning brings
    users into the directory from a connected HR system or a file import.
    **Outbound** provisioning pushes account creation, updates, and removal from
    the directory into your connected apps, so an app account exists exactly while
    access is granted. See [Provisioning](/en/identity/applications/provisioning).
  </Accordion>
</AccordionGroup>

## Trust and policy objects

<AccordionGroup>
  <Accordion title="Authentication policies" icon="shield-halved">
    A **policy** is a set of rules that decides whether a sign-in is allowed and
    what the user must prove first. When someone signs in to an app, Iru
    evaluates the governing policy and records the decision. See
    [Authentication policies](/en/identity/authentication/authentication-policies).
  </Accordion>

  <Accordion title="Authenticators" icon="key">
    An **authenticator** is something a user uses to prove who they are, such
    as a **passkey** or Iru Access. Users manage their own authenticators in
    self-service, and a strong authenticator is required for every sign-in. See
    [Authenticators](/en/identity/authentication/authenticators).
  </Accordion>

  <Accordion title="Risk and device trust" icon="gauge-high">
    Policies take the device into account. **Device trust** reflects whether the
    user is on a known, healthy device and can be a required condition for
    access. **Risk levels** are a classification you assign to organize apps by
    sensitivity. See
    [Risk and adaptive access](/en/identity/authentication/risk-based-access) and
    [Device trust](/en/identity/authentication/device-trust).
  </Accordion>

  <Accordion title="Federated Authentication" icon="plug">
    An **identity provider connection** lets users sign in to the Iru platform
    through a provider you already run. Use this when Iru Identity is an
    authentication layer rather than your primary identity provider, or to ease a
    migration. See [Federated Authentication](/en/identity/connections/connections-overview).
    (To bring users into the directory from an HR system instead, see
    [Directory Sync](/en/identity/directory/directory-sync).)
  </Accordion>
</AccordionGroup>

## Administration objects

| Object                     | What it is                                                                                                          |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Organization**           | Your tenant: the isolated Iru environment that holds your directory, apps, and settings, including branding.        |
| **Administrators & roles** | The administrators who manage Iru Identity and the roles that define what each can do.                              |
| **Activity log**           | A record of significant events (who did what, and the results of sign-in decisions) that you can review and filter. |

## How a sign-in uses these objects

1. A user tries to open an **application**, which redirects them to Iru to
   sign in.
2. The user authenticates to Iru with a passkey or the Iru Access app, or
   through a connected provider, and Iru identifies the matching **user** in the
   **directory**.
3. The application's **authentication policy** evaluates the sign-in for **device
   trust**. The user has already proven who they are with their authenticator
   in the previous step.
4. If the policy passes and the user is assigned the **application**, Iru issues
   the sign-on and the user reaches the app.
5. The **activity log** records the outcome.

<Tip>
  Assign access to **groups**, and base group membership on **attributes** where
  you can. Access then follows users automatically as their profiles change.
  That's lifecycle automation in Iru Identity.
</Tip>