Skip to main content
When your identity provider speaks the SAML standard but is not covered by a ready-made template, connect it as a custom SAML connection. In this setup Iru acts as the service provider (SP): your provider authenticates the person, then sends Iru a signed SAML response that Iru trusts to start the session.
Most organizations that use Iru Identity as their identity provider have people sign in directly with a passkey or the Iru Access app. Connect a SAML provider when you use Iru Identity as an authentication layer into the Iru platform rather than your primary identity provider, or to ease a migration onto Iru Identity. See Federated Authentication.
You need administrator access to your Iru tenant, and administrator access to your SAML identity provider, to complete this connection. Setting up SAML means exchanging a few values in both directions - this page walks through both sides.

​
How the trust is established

Iru and your provider each need to trust the other. Iru gives you the details your provider needs to recognize Iru, and your provider gives you the details Iru needs to verify its responses.

​
Before you begin

1

Gather Iru's service provider details

From the connection in Iru, collect the values your provider will ask for - Iru’s SP metadata, its entity ID, and its ACS URL (the address where your provider sends its SAML response). Many providers can import this in one step from the metadata.
2

Gather your provider's details

From your SAML provider, collect its entity ID, its single sign-on URL, and its signing certificate (the certificate Iru uses to verify the provider’s signed responses).
3

Make sure your people exist in Iru

Sign-in through a connection resolves to an existing Iru user. Add or import your people first - see Importing users or Directory Sync.

​
Connect a SAML provider

Add the connection

In Access → Authentication, add an authentication method and choose SAML. Iru generates its service provider details for this connection.

Register Iru with your provider

In your SAML provider, create a new application (relying party) for Iru and supply Iru’s entity ID and ACS URL, or import Iru’s SP metadata if your provider supports it. Configure the provider to release the NameID and any attributes you intend to match on. The exact relying-party screens live in your provider’s console; follow its current documentation.

Enter your provider's details in Iru

Back in Iru, enter your provider’s entity ID and single sign-on URL, then upload your provider’s signing certificate so Iru can verify the SAML responses it receives.

Set user matching

Tell Iru which value in the SAML response identifies the person - the Subject (NameID) or a named attribute the provider sends - and which Iru user value to match it against (UPN, username, external ID, or a custom attribute). See user matching.

Choose what the connection is used for

Select the connection’s use cases - end-user sign-in, device enrollment, or both.

Restrict to your domains

If you want only people in specific email domains to use this connection, enable domain restrictions and add those domains.

Save and test

Save the connection, then sign in as a test user to confirm the round trip: Iru sends the request, your provider authenticates the person, and Iru matches them to the right user.
Iru can also present a request-signing certificate so your provider can verify that sign-in requests genuinely came from Iru. If your provider expects signed requests, share Iru’s request-signing certificate from the connection and enable signed requests on the provider side.

​
Keeping the connection healthy

The signing certificate you upload from your provider has an expiry date. When your provider rotates its certificate, upload the new one in Iru so sign-in keeps working. Plan the swap before the old certificate expires.
This almost always traces back to user matching. Confirm the value your provider sends (the Subject or attribute) is present and unique for everyone, and that it matches the Iru user value you selected.

Federated Authentication

Use cases, domain restrictions, and user matching, explained in one place.

Custom OIDC

Connect an identity provider that uses OpenID Connect instead of SAML.

System architecture

See how federated sign-in fits into the wider identity layer.

Sign-in experience

Shape what people see when they sign in.