Skip to main content
Iru Identity is built from a small set of objects. Once you know what each one is and how they connect, the rest of the product follows naturally.

​
The big picture

​
Identity objects

A user is a person 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 your people 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 users or groups to an application. The full set of people who end up with access - directly or through a group - is the application’s effective users. Assign to groups whenever you can, so access follows directory membership. See Assigning access.
Provisioning keeps accounts in sync. Inbound provisioning brings people 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 person 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 person uses to prove who they are, such as a passkey or Iru Access. People 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 person 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 people sign in to the Iru platform through a provider you already run - used when Iru Identity is an authentication layer rather than your primary identity provider, or to ease a migration. See Federated Authentication. (To bring people into the directory from an HR system instead, see Directory Sync.)

​
Administration objects

ObjectWhat it is
OrganizationYour tenant - the isolated Iru environment that holds your directory, apps, and settings, including branding.
Administrators & rolesThe people who manage Iru Identity and the roles that define what each can do.
Activity logA record of significant events - who did what, and the results of sign-in decisions - that you can review and filter.

​
How a sign-in uses these objects

  1. A person tries to open an application, which redirects them to Iru to sign in.
  2. The person 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 person 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 person 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 people automatically as their profiles change, which is the heart of lifecycle automation in Iru Identity.