Skip to main content
Many applications expect to know what role a person has - administrator, member, viewer, and so on - not just who they are. Iru can assert a role to an application at sign-on, decided by the person’s group membership, and can vary session length and risk by role. You configure this on an application’s Roles tab. Like the rest of an app, you edit it in a draft and publish it - see Applications overview.

How a role reaches the application

A role is granted to one or more groups. When someone in those groups signs on, Iru asserts the role’s identifier to the application using the method you choose.

Role assertion method

This decides how - or whether - the role is sent to the application.
MethodWhat it does
NoneThe application does not receive a role over single sign-on. Role bundles are turned off.
GroupsThe role identifier(s) are sent as values in the groups the application receives.
Custom attributeThe role identifier(s) are sent in a custom attribute or claim you name - as a single value or an array. For SAML apps you also choose the attribute name format.

Role bundles

Roles live inside role bundles, which group related roles and decide whether a person can hold more than one of them at once.
Bundle settingWhat it does
Display nameThe bundle’s name in the dashboard.
Bundle identifierA unique identifier used only to organize related roles. It is not sent to the application as a role value.
Exclusivity modeInclude all asserts every role the person qualifies for in the bundle. Priority asserts only the single highest-priority role, so the roles are mutually exclusive.
In Priority mode, each role carries a unique priority number, and the role with the best priority wins when someone qualifies for more than one.

What a role contains

The role’s name in the dashboard, and the role identifier that is asserted to the application (the value the app receives for this role).
The groups whose members receive the role. Basing roles on groups keeps role assignment following your directory.
How long a session granted through this role lasts, in minutes. Different roles can carry different session lengths.
An optional risk level classification for the role, so you can label more sensitive roles consistently.
Every application starts with a Default bundle and role, so access works out of the box. Add bundles and roles only when an application needs role-based access.

Configure roles for an application

Choose the role assertion method

On the app’s Roles tab, set how roles should reach the application - Groups or a Custom attribute - or None if the app doesn’t take a role over single sign-on.

Create a role bundle

Add a bundle, give it a name and identifier, and choose Include all or Priority exclusivity.

Add roles

For each role, set its identifier, assign the groups that should receive it, and set the session duration and (optionally) a risk level. In Priority bundles, give each role a priority number.

Publish

Set the draft as current. From then on, sign-on asserts each person’s role according to your bundles.

Where to go next

Assigning access

Grant who can reach the app in the first place.

Groups

Roles are granted to groups - organize membership there.

SAML applications

Where the custom attribute name format is set for SAML role assertion.

OIDC applications

Where roles ride along as a claim for OIDC apps.