Map identity provider attributes and groups

What this achieves

Attribute mapping tells Humavera which piece of your identity provider’s response is a person’s name, email, and group membership. Group mapping turns those groups into roles, so what somebody can do in Humavera follows what your directory already says about them.

Required role: Administrator.

Before you start

Configure the provider first. You also need to know the exact claim names your provider sends, particularly the one carrying group membership — it differs between providers and between configurations of the same provider.

Steps

Go to Integrations → SSO.
Under Attribute Mapping, enter the claim name your provider sends for each Humavera field.
Enter the claim that contains the user’s groups.
Under Group → Role Mapping, select Add mapping.
Enter the identity provider group name and choose the Humavera role it maps to.
Repeat for each group you want mapped.
Under Allowed Email Domains, add the domains permitted to provision, or leave it empty.
Under Email-Domain Login Routing, add the domains that should route to your organization’s provider.
Select Save Changes.

Attribute mapping

Map the provider’s claims to Humavera fields. The groups claim is the one to get exactly right — the screen names two common examples, and if you enter one your provider does not send, every mapped role silently fails to apply.

Example: HC Corp’s provider sends group membership in a claim the provider’s own documentation names. Entering the wrong claim produces users who provision successfully and arrive with no role at all.

Group to role mapping

Behaviour	What the screen states
When roles apply	Users receive the mapped role on first login, and it is refreshed on subsequent logins.
Matching	Group names are matched case-insensitively.
With no mappings	Auto-provisioned users are created without a role until you assign one manually.

The refresh-on-every-login behaviour is the point of this feature and the thing to be deliberate about. Your directory becomes the authority on access, and a role assigned by hand in Humavera is overwritten the next time that person signs in if a mapping covers them.

Example: HC Corp maps its engineering directory group to the Manager role. Moving someone out of that group in the directory removes their manager access at their next sign-in, without anyone touching Humavera.

Map few groups rather than many. Every mapping is a rule somebody will have to reason about in two years when access is wrong and nobody remembers why.

Allowed email domains

This is a whitelist of email domains permitted to auto-provision through single sign-on. Leave it empty to accept any domain your provider asserts.

The screen states the rule that catches people out: it applies on first login. Tightening the list later does not remove anyone who is already in — existing users keep working.

Example: HC Corp restricting provisioning to hc-corp.example stops a contractor account on another domain from creating a Humavera user. Adding that restriction six months in does nothing about the contractor accounts already created.

This is a different list with a different job, and the screen says so. A routing domain sends a login straight to your organization’s provider — somebody typing an address at that domain on the sign-in screen goes to your identity provider rather than being asked which workspace they want.

Option	Description
Allowed Email Domains	Gates which domains may auto-provision an account.
Email-Domain Login Routing	Decides which domains route a sign-in attempt to this organization’s provider.

A routing domain is globally unique: it can belong to only one organization. With no routing domains set, people sign in via the workspace name instead.

Example: HC Corp adding hc-corp.example as a routing domain means Priya Raman types her work address and lands at her company’s login. Nobody else can claim that domain.

Only add a domain your organization actually controls. A claimed domain routes every sign-in attempt at that domain to your provider.

What happens next

Mapping does not take effect until the configuration is tested and activated. Test the connection, check that a real person arrives with the role you expected, and only then consider enforcement. A group mapping that is subtly wrong is far easier to find with one test user than with everybody at once.