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

# System architecture

> Understand how identities, sign-in, and provisioning flow through Iru Identity, and the architectural guarantees that protect data and isolate tenants.

Iru Identity is the identity layer between your people, the systems that know
about them, and the applications they use. This page explains how those pieces
connect so you can reason about sign-in, provisioning, and access decisions.

## The identity layer

```mermaid theme={null}
flowchart LR
  subgraph people["Your people"]
    emp["Employees and contractors"]
  end
  hr["HR system<br/>(who exists)"]
  idp["Existing provider<br/>(optional · migration)"]
  subgraph iru["Iru Identity"]
    dir["Directory"]
    engine["Policy engine"]
    prov["Provisioning"]
  end
  subgraph apps["Where people work"]
    saas["Your applications"]
  end

  hr -->|"sync people"| dir
  emp -->|"sign in with a passkey"| engine
  idp -. "optional sign-in" .-> engine
  dir --> engine
  engine -->|"allowed access"| saas
  dir --> prov
  prov -->|"accounts"| saas
```

Iru Identity is, first and foremost, **your identity provider**. Your people
sign in to Iru directly - typically with a passkey or the Iru Access app - and
Iru vouches for who they are to every connected app, sending each one a signed
statement of identity using the SAML or OIDC standard it supports.

Iru can **also act as a relying party** to an identity provider you already
operate: it hands sign-in off to that provider and continues the session once
the provider confirms the person. This is a secondary path, meant for two
situations:

* **Signing in to the Iru platform with an existing provider.** Every Iru tenant
  uses Iru Identity to manage admins and keep users in sync, but not every
  organization uses it as their full identity provider. When Iru Identity is the
  authentication layer into Iru and its products, people can sign in with the
  provider you already run.
* **Easing a migration.** While you move onto Iru Identity as your identity
  provider, people can keep signing in through their current provider during the
  transition.

## How sign-in works

```mermaid theme={null}
sequenceDiagram
  participant U as Person
  participant A as Application
  participant I as Iru Identity
  participant P as Connected provider

  U->>A: Open the app
  A->>I: Ask Iru to authenticate
  alt Direct sign-in (default)
    I->>U: Prompt for a passkey or Iru Access
    U-->>I: Prove identity
  else Federated sign-in (auth layer or migration)
    I->>P: Hand off to your existing provider
    P-->>I: Confirm the person
  end
  I->>I: Evaluate the authentication policy
  alt Policy passes
    I-->>A: Issue single sign-on
    A-->>U: Grant access
  else Policy fails
    I-->>U: Deny and explain why
  end
```

Every sign-in to a connected app is checked against that app's authentication
policy. A strong authenticator is always required; the policy then evaluates
device trust before access is granted. Iru records the decision in
the [activity log](/en/identity/administration/activity-log).

## How provisioning works

Provisioning keeps your directory and your apps aligned with reality, in two
directions.

<Tabs>
  <Tab title="Inbound (into Iru)">
    People enter the directory from a source of truth:

    ```mermaid theme={null}
    flowchart LR
      hr["HR system"] -->|"scheduled sync"| dir["Directory"]
      file["User import"] -->|"on upload"| dir
      manual["Manual entry"] --> dir
      dir -->|"attributes drive"| groups["Group membership"]
    ```

    A connected HR system syncs people on a schedule, a file import brings in a
    batch at once, and you can always add users by hand. As profiles arrive,
    [Auto Groups](/en/identity/directory/auto-groups) update their
    membership automatically.
  </Tab>

  <Tab title="Outbound (into your apps)">
    Access changes flow out to connected applications:

    ```mermaid theme={null}
    flowchart LR
      dir["Directory"] -->|"assigned access"| prov["Provisioning"]
      prov -->|"create or update"| app["App account"]
      prov -->|"remove on offboarding"| app
    ```

    When you assign someone to an app that supports provisioning, Iru creates and
    updates their account there. When access is removed, Iru can remove the
    account. Iru keeps a history of these syncs so you can confirm what happened.
    See [Provisioning](/en/identity/applications/provisioning).
  </Tab>
</Tabs>

## Iru Access

**Iru Access** is the Iru app people install on their computer or mobile device.
It plays two roles at once:

* **Authenticator** - it holds a device-bound, passkey-style credential people use
  to sign in, unlocked by the device's biometric or screen lock.
* **Device agent** - it reports the device's health signals to Iru, which your
  [device-trust](/en/identity/authentication/device-trust) policies can require.

Because it's both, a single app gives people fast, phishing-resistant sign-in and
gives you device posture for access decisions - with no separate agent to deploy.

## Device trust signals

The Iru Access agent on each device reports device health - such as whether the
device is encrypted and healthy - to Iru, where your authentication policies can
use it. A policy can then require a known, healthy device before granting access.
See [Device trust](/en/identity/authentication/device-trust).

## Guarantees that protect your tenant

Iru Identity is designed so that the sensitive job of authentication stays
trustworthy. In plain terms:

<CardGroup cols={2}>
  <Card title="Tenant isolation" icon="box">
    Your directory, apps, and settings live in your own tenant. One
    organization's data is never visible to another.
  </Card>

  <Card title="Verifiable sign-on" icon="signature">
    The identity statements Iru sends to your apps are signed so each app can
    confirm they genuinely came from Iru and were not altered in transit.
  </Card>

  <Card title="Protected credentials" icon="lock">
    Authenticators such as passkeys are stored and verified so that the secret
    needed to sign in never has to be shared with the apps you use.
  </Card>

  <Card title="Encrypted everywhere" icon="shield">
    Information is protected in transit between your people, Iru, and your apps,
    and while it is stored.
  </Card>
</CardGroup>

For how credentials and sessions are protected, and how to think about data and
privacy, see [Security and privacy](/en/identity/security/security-and-privacy).

## Where to go next

<CardGroup cols={2}>
  <Card title="Key concepts" icon="book" href="/en/identity/getting-started/key-concepts">
    Review the objects referenced above and how they relate.
  </Card>

  <Card title="Federated Authentication" icon="plug" href="/en/identity/connections/connections-overview">
    Connect an identity provider your people already sign in with.
  </Card>

  <Card title="Authentication policies" icon="shield-halved" href="/en/identity/authentication/authentication-policies">
    Decide who can sign in to each app and what they must prove.
  </Card>

  <Card title="Applications" icon="grip" href="/en/identity/applications/applications-overview">
    Connect the apps your people sign in to.
  </Card>
</CardGroup>