Skip to main content
A SAML application lets people sign in to a service that supports SAML single sign-on, with Iru acting as the identity provider (IdP). Iru gives the service the provider-facing details it needs, signs the response and assertion it sends, and maps your users’ profile attributes into that assertion. You edit a SAML app’s configuration in a draft and then set it as the current version - see Applications overview for the version model. This page is a field-by-field reference for every setting, grouped exactly as the editor presents them.
Most services need only a handful of these settings - typically the ACS URL, the Service Provider Entity ID, and the mapping. The defaults are chosen to work with common service providers; change the rest only when your service’s documentation calls for it.

​
Protocol details - what Iru gives the service provider

Open the application’s Protocol details to copy the values your service provider needs to trust Iru. These are generated by Iru.
DetailWhat it is
Metadata URLA single document describing Iru’s SAML settings for this app. Many services configure everything from this URL; you can also view or download the metadata file.
IdP Entity IDIru’s identifier as the identity provider for this app.
Single Sign On ServiceThe URL the service provider sends authentication requests to (and where IdP-initiated sign-on begins).
IdP Signing CertificateThe certificate the service uses to verify that a response genuinely came from Iru. Its subject, expiry, and fingerprint are shown, and you can copy or download it.
If the service can import metadata, point it at the Metadata URL (or upload the downloaded file) - it carries the entity ID, sign-on URL, and signing certificate together, so there is less to enter by hand.

​
Provider details - what you tell Iru about the service

SettingWhat it does
ACS URLThe Assertion Consumer Service URL - the destination Iru sends the SAML response to. Required, and must be a valid https URL.
Service Provider Entity IDThe service provider’s own identifier. Iru uses it as the default audience and (optionally) to validate the request issuer.
Unsolicited authenticationWhether the service supports IdP-initiated sign-on (the person starts from Iru). Set Supported if the service accepts a response it didn’t request; otherwise set Unsupported.
Alternative authentication URLShown when unsolicited authentication is Unsupported: the URL Iru sends people to so the service can start the sign-in itself (service-provider-initiated).

​
Request - how Iru handles the service’s authentication requests

These settings govern the AuthnRequest that a service provider sends to start sign-on.

​
Validate issuer

How strictly Iru checks the Issuer in an incoming request.
OptionWhat it does
Must match Service Provider Entity IDThe request’s issuer must equal the Service Provider Entity ID you entered above.
Must match custom valueThe issuer must equal a Custom value you specify (use this when the service’s issuer differs from its entity ID).
IgnoreDo not validate the issuer.

​
Authentication request restriction

Controls whether the request must be signed and which ACS URL Iru replies to. “Follow” uses the ACS URL from the request; “pinned” always uses the ACS URL configured in Provider details.
OptionRequest must be signed?Response is sent to
Any request and followNoThe ACS URL in the request
Any request and pinnedNoThe configured ACS URL
Signed request and followYesThe ACS URL in the request
Signed request and pinnedYesThe configured ACS URL
Pinned is the safer choice: it ignores any ACS URL supplied in the request, so a tampered request cannot redirect a response elsewhere. Prefer Signed request and pinned when the service supports signing its requests.
When you choose a Signed request option, you also set how Iru verifies that signature:
SettingWhat it does
Allowed signing algorithmsThe request signature algorithms Iru will accept - any of RSA-SHA1, RSA-SHA256, RSA-SHA384, RSA-SHA512. Select the ones your service uses; avoid RSA-SHA1 unless required.
Allowed digest algorithmsThe request digest algorithms Iru will accept - any of SHA1, SHA256, SHA384, SHA512.
Signing CertificateThe certificate Iru uses to verify the service’s signed requests. Upload the service provider’s request-signing certificate.

​
Response - how Iru builds and sends the assertion

​
Delivery and identifiers

SettingWhat it does
HTTP MethodHow the SAML response is delivered: HTTP-POST (an auto-submitting form - the common choice) or HTTP-REDIRECT.
IdP Entity IDThe issuer Iru declares in the response. Leave on Use default (shown in Protocol details), or choose Specify custom to declare a different Custom IdP Entity ID.
AudienceWho the assertion is intended for. Use default sends the Service Provider Entity ID; choose Specify custom to send a different Custom Audience.
RecipientThe recipient declared in the assertion. Use default uses the ACS URL (the destination); choose Specify custom to send a different Custom Recipient.
Fallback relay valueThe RelayState Iru uses when the service didn’t supply one - typically where the person should land in the app.
Error actionWhat happens when a sign-on can’t complete: Iru shows an Iru error page, or Protocol returns the error to the service provider to handle.

​
Signing

SettingWhat it does
Signing methodWhich parts of the message Iru signs: Response, Assertion, or Both - Response and Assertion. Match what the service requires.
Signing algorithmThe signature algorithm Iru signs with - RSA-SHA1, RSA-SHA256, RSA-SHA384, or RSA-SHA512. RSA-SHA256 suits most services.
Digest algorithmThe digest algorithm used in the signature - SHA1, SHA256, SHA384, or SHA512.
Iru signs with its own IdP Signing Certificate (the one shown in Protocol details), so there is no signing certificate to upload here.

​
Encrypt assertions

SettingWhat it does
Encrypt assertionsUnencrypted (default) or Encrypted. Turn on only if the service requires encrypted assertions.
Use the Request signing certificateWhen encrypting, reuse the service’s request-signing certificate as the encryption certificate instead of uploading a separate one. (Requires a signing certificate to be configured in the Request section.)
Encryption CertificateThe service provider’s certificate Iru encrypts the assertion to, when you are not reusing the request-signing certificate.
Encryption algorithmThe content-encryption algorithm: AES-128-GCM, AES-192-GCM, AES-256-GCM, AES-128-CBC, AES-192-CBC, or AES-256-CBC. Use what the service expects (a GCM option is a good default).
Key transport algorithmHow the encryption key is protected: RSA-OAEP or RSA-PKCS1-v1.5.

​
Advanced

SettingWhat it does
Use namespace prefixesAdds explicit XML namespace prefixes (saml2p, saml2, ds, xenc) to the response. Enable it if the service’s SAML parser requires prefixed elements.

​
Mapping - the NameID and attributes Iru sends

Open the application’s mapping to control the identity in the assertion. It has two parts: the Subject (the NameID) and any additional attributes.

​
Subject (NameID)

The Subject is the primary identifier for the signed-in person. By default it is drawn from the user’s user.username; you can change the value it draws from and choose a NameID format:
NameID formatUse when the service expects…
EmailAn email address as the identifier.
PersistentA stable, opaque identifier that stays the same across sessions.
TransientA temporary identifier that may change each session.
UnspecifiedNo particular format.

​
Attributes

Add each attribute the service needs in the assertion. For every attribute you set:
  • A Name - the attribute name the service provider expects.
  • A value - the profile attribute or expression it draws from (for example, user.email or a combination of fields).
  • An attribute name format - Unspecified, URI, or Basic.
  • Whether it is enabled.
A live preview renders the assertion that will be produced, so you can confirm its shape before publishing.
Subject is reserved as the NameID and cannot be reused as a custom attribute name.

​
Session management

SettingWhat it does
Session Length SupportedSupported populates the assertion’s notOnOrAfter (session expiry) from the length below; Unsupported omits it.
Default session length (minutes)The session length written into the assertion. Must be between 10 and 2880 minutes; defaults to 480 (8 hours).

​
Certificates at a glance

A SAML app involves up to three certificates:
Iru signs the response and/or assertion with its own certificate, shown in Protocol details. The service uses it to confirm the message came from Iru and was not altered. Nothing to upload.
Upload the service provider’s certificate so Iru can verify the signed authentication requests it sends. Configured in the Request section, and only needed when you require signed requests.
The service provider’s certificate Iru encrypts the assertion to, used only when Encrypt assertions is on. You can reuse the request-signing certificate instead of uploading a separate one.

​
Publish, assign, and activate

1

Set the draft as current

Publish your draft so it becomes the live configuration.
2

Assign access

Assign the users or groups who should have the app. See Assigning access.
3

Activate

Make the app active so assigned people can sign in.
4

Test the sign-on

Sign in as a test user from the app dashboard to confirm the experience, and use the mapping preview to check the assertion.

​
Where to go next

Assigning access

Grant the app to users and groups, and shape app roles.

Provisioning

Create and remove accounts in the app automatically as access changes.

OIDC applications

Configure an app that uses OpenID Connect instead of SAML.

Applications overview

Review protocols and the draft-to-current version model.