The identity layer
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
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.How provisioning works
Provisioning keeps your directory and your apps aligned with reality, in two directions.- Inbound (into Iru)
- Outbound (into your apps)
People enter the directory from a source of truth: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 update their
membership automatically.
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 policies can require.
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.Guarantees that protect your tenant
Iru Identity is designed so that the sensitive job of authentication stays trustworthy. In plain terms:Tenant isolation
Your directory, apps, and settings live in your own tenant. One
organization’s data is never visible to another.
Verifiable sign-on
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.
Protected credentials
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.
Encrypted everywhere
Information is protected in transit between your people, Iru, and your apps,
and while it is stored.
Where to go next
Key concepts
Review the objects referenced above and how they relate.
Federated Authentication
Connect an identity provider your people already sign in with.
Authentication policies
Decide who can sign in to each app and what they must prove.
Applications
Connect the apps your people sign in to.