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

# Federated authentication connections

> Link Iru Identity to an identity provider your people already sign in with, to use Iru as an authentication layer or while migrating users onto it.

A **connection** links Iru Identity to an external system you already run. In the
dashboard, identity-provider connections live under **Access → Authentication**,
and HR-system connections live under **Directory → Sync**.

By default, Iru Identity is your **identity provider** - your people sign in
directly with a passkey or the Iru Access app. An **identity provider connection**
lets them sign in through a provider you already run instead - useful when you use
Iru as an authentication layer into the Iru platform, or while migrating onto Iru
Identity.

<Note>
  Looking to sync people from an HR system? That's a separate, directory-side
  feature - see [Directory Sync](/en/identity/directory/directory-sync)
  under **Directory → Sync**.
</Note>

```mermaid theme={null}
flowchart LR
  people["Your people"]
  idp["Existing provider<br/>(optional · migration)"]
  subgraph iru["Iru Identity"]
    signin["Sign-in"]
  end
  people -->|"sign in (passkey)"| signin
  idp -. "optional sign-in" .-> signin
```

<Note>
  These connections are how Iru reaches systems you already operate. To connect the
  apps your people *sign in to*, see
  [Applications](/en/identity/applications/applications-overview). For how Iru
  sits between your people, your providers, and your apps, see
  [System architecture](/en/identity/getting-started/system-architecture).
</Note>

## Identity provider connections

By default your people sign in to Iru directly. An identity provider connection
lets them sign in through a provider you already operate instead. Reach for one
in two situations:

<Info>
  **When to connect an identity provider**

  * **Iru Identity as an authentication layer.** 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. If you use Iru mainly as the way
    people sign in to the Iru platform, connect the provider you already run so
    they can sign in with familiar credentials.
  * **Migrating to Iru Identity.** When you are moving from an existing provider
    to Iru Identity as your identity provider, connecting your current provider
    lets people keep signing in the usual way while you make the transition.
</Info>

Iru supports these connection types:

| Type          | Use it for                                                                                 |
| ------------- | ------------------------------------------------------------------------------------------ |
| **Google**    | Sign-in backed by Google accounts. A **Google Workspace** template streamlines setup.      |
| **Microsoft** | Sign-in backed by Microsoft accounts. A **Microsoft Entra ID** template streamlines setup. |
| **SAML**      | Any identity provider that speaks the SAML standard.                                       |
| **OIDC**      | Any identity provider that speaks the OpenID Connect standard.                             |

Iru also has a built-in sign-in option of its own, so you can connect an external
provider for some people while others continue to sign in directly with an
[authenticator](/en/identity/authentication/authenticators) such as a passkey.

<Tip>
  The **Google Workspace** and **Microsoft Entra ID** templates pre-fill the
  standard configuration so you only supply what is specific to your tenant.
  Reach for them before configuring a generic SAML or OIDC connection by hand.
</Tip>

### What you configure on every identity provider connection

<AccordionGroup>
  <Accordion title="Use cases" icon="list-check">
    Each connection has one or more **use cases** that decide where it applies:

    * **End-user sign-in** - people use the connection to sign in to Iru and
      reach their apps.
    * **Device enrollment** - the connection is used while enrolling a device.

    You choose what a connection is used for, and a single connection can serve
    more than one use case.
  </Accordion>

  <Accordion title="Domain restrictions" icon="at">
    You can restrict a connection to one or more email **domains**, so only
    people whose email is in those domains use it. This lets you route different
    parts of your organization to different providers.
  </Accordion>

  <Accordion title="User matching" icon="user-check">
    When someone signs in through a connection, Iru matches them to a user in
    your [directory](/en/identity/directory/directory-overview) so the sign-in
    resolves to the right person. You choose what Iru matches on:

    | Match on             | What it is                                                       |
    | -------------------- | ---------------------------------------------------------------- |
    | **UPN**              | The user principal name the provider sends.                      |
    | **Username**         | The user's username.                                             |
    | **External ID**      | An identifier carried from the provider.                         |
    | **Custom attribute** | A [profile attribute](/en/identity/directory/schema) you choose. |

    Pick the value that is stable and unique for every person, so each sign-in
    lands on exactly one user.
  </Accordion>
</AccordionGroup>

<CardGroup cols={2}>
  <Card title="Google Workspace" icon="google" href="/en/identity/connections/google-workspace">
    Connect Google Workspace for end-user sign-in using the template.
  </Card>

  <Card title="Microsoft Entra ID" icon="microsoft" href="/en/identity/connections/microsoft-entra-id">
    Connect Microsoft Entra ID for end-user sign-in using the template.
  </Card>

  <Card title="Custom SAML" icon="shield-halved" href="/en/identity/connections/custom-saml">
    Connect any SAML identity provider, with Iru acting as the service provider.
  </Card>

  <Card title="Custom OIDC" icon="key" href="/en/identity/connections/custom-oidc">
    Connect any OpenID Connect identity provider.
  </Card>
</CardGroup>

## Device trust signals

Device health is not a connection. Signals such as whether a device is encrypted
and healthy are reported by the **Iru Access** agent on each device, and your
[authentication policies](/en/identity/authentication/authentication-policies)
can require a known, healthy device before granting access. See
[Device trust](/en/identity/authentication/device-trust).

## Where to go next

<CardGroup cols={2}>
  <Card title="Key concepts" icon="book" href="/en/identity/getting-started/key-concepts">
    See how connections relate to users, groups, applications, and policies.
  </Card>

  <Card title="Sign-in experience" icon="arrow-right-to-bracket" href="/en/identity/authentication/sign-in-experience">
    Shape what people see when they sign in through a connected provider.
  </Card>
</CardGroup>