Advanced settings and configuration for other providers

Configuring SSO add-ons

Plus addressing fallback

Enabling this feature is helpful if your organisation works in different accounts (not sub-accounts) in Refapp. If the same user requires access to multiple accounts through SSO.

The setting is placed on the account so that users can log in with the same email address. When the administrator sets it up, they input what the fallback should be. Users don't need to do anything during login; the system recognizes that there's a fallback for that domain and creates a user with the fallback on the account being logged into after the user was created on the other account.

Map access rights via SSO

This feature can automate the process of assigning user roles, reducing the manual work required by administrators. Users can be assigned roles based on their specific attributes, ensuring that they only have access to the resources they need. This can help to improve security by ensuring that users only have access to the level of access they require.

• If your company wants to use this feature,  your IT team will need to customize your configuration for Refapp in the SSO Identity provider.

• We can provide additional guidance on how we implemented this feature using Entra (Azure AD) if your company is using that system.

• See table Extra Attributes and Roles for additional information to set up access-right mapping. 

Subbaccount Mapping

Refapp subaccounts are used to separate users into different divisions within your organisation. 

A user can be assigned to one or more subaccounts and this controls access to projects, questionnaires, and other data in the system.

When onboarding a new user, the built-in functionality is to use their email domain to map to subaccounts. Administrators can override these settings manually once the user has been onboarded.

In larger organisations, this does not scale well since the email domain is not specific enough to control access to subaccounts.

To solve the issue above, we introduce a new setting for each subaccount when SSO is enabled in Refapp to specify one or more names of SSO IdP groups that should give access to the subaccount.

The corresponding SAML loginResponse payload would then need to contain something like:

in order for the logged-in user to be assigned to the subaccount, i.e. if the user belongs to one of the listed groups, they are assigned.

The name of the attribute (claim) must be one of these:

• The Azure AD default: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
• The SAML specification default:
  http://schemas.xmlsoap.org/claims/Group