Skip to main content
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

​
Identity objects

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.
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.
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 and Auto Groups.

​
Access objects

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

​
Trust and policy objects

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.
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.
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 and Device trust.
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. (To bring users into the directory from an HR system instead, see Directory Sync.)

​
Administration objects

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