Skip to main content
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.
Looking to sync people from an HR system? That’s a separate, directory-side feature - see Directory Sync under Directory → Sync.
These connections are how Iru reaches systems you already operate. To connect the apps your people sign in to, see Applications. For how Iru sits between your people, your providers, and your apps, see System architecture.

​
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:
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.
Iru supports these connection types:
TypeUse it for
GoogleSign-in backed by Google accounts. A Google Workspace template streamlines setup.
MicrosoftSign-in backed by Microsoft accounts. A Microsoft Entra ID template streamlines setup.
SAMLAny identity provider that speaks the SAML standard.
OIDCAny 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 such as a passkey.
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.

​
What you configure on every identity provider connection

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.
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.
When someone signs in through a connection, Iru matches them to a user in your directory so the sign-in resolves to the right person. You choose what Iru matches on:
Match onWhat it is
UPNThe user principal name the provider sends.
UsernameThe user’s username.
External IDAn identifier carried from the provider.
Custom attributeA profile attribute you choose.
Pick the value that is stable and unique for every person, so each sign-in lands on exactly one user.

Google Workspace

Connect Google Workspace for end-user sign-in using the template.

Microsoft Entra ID

Connect Microsoft Entra ID for end-user sign-in using the template.

Custom SAML

Connect any SAML identity provider, with Iru acting as the service provider.

Custom OIDC

Connect any OpenID Connect identity provider.

​
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 can require a known, healthy device before granting access. See Device trust.

​
Where to go next

Key concepts

See how connections relate to users, groups, applications, and policies.

Sign-in experience

Shape what people see when they sign in through a connected provider.