IdP routing rules

Console: Identity → IdP Routing Rules, at /iam/idp-routing. An ordered, organisation-scoped table that decides, for one sign-in, whether it should be handled locally by Qorionix or handed off to an external identity provider you have already configured — before the person's password is ever looked at.

How a rule matches

Every rule has a priority (lower number considered first), an optional list of email domains, an optional list of network zone names, and a target. Rules are evaluated in priority order and the first ACTIVE rule whose conditions match wins — the identical first-match-wins shape as the ordered authentication policy in Sign-on policies and the decision trace, applied to a different question.

• Domains and networks are each optional, but not both. A rule must name at least one; the console refuses to save one with neither, and so does the API.
• A rule with only a domain list ignores network entirely, and vice versa. Name both and a sign-in must satisfy both to match — the two conditions are ANDed, not ORed.
• Domain matching is exact and case-insensitive, against the portion of the email address after the last @. Use * as a domain entry to match every domain — a catch-all rule for the bottom of your list, not a wildcard prefix or suffix match.
• Network matching checks the zones the sign-in's address resolved into — the same zones described in Network zones — case-insensitively, against any zone the rule names. One shared zone name in common between the rule and the request is enough.
• Inactive rules never match. Set a rule INACTIVE to keep it configured but out of the running, the same convention the sign-on-policy engine uses for its own rules.
• Nobody matched signs in locally — the same behaviour as today, for an organisation that never touches this screen at all.

The target: local, or an identity provider

Picking the federation target requires choosing a provider from the same list your SAML or OIDC setup already populated. If your organisation has not configured a provider yet, the form says so and there is nothing to pick — set one up first.

Where this runs in the sign-in path

The check happens at the very start of Login, before any credential is checked — local password or Active Directory-delegated alike. The reasoning is direct: a rule that is supposed to send [email protected] to your SAML provider must not be bypassable by somebody who still happens to know that account's local Qorionix password. If a rule matches and routes to a provider, the response is HTTP 200 with {"federated": true, "provider_id": ..., "provider_slug": ..., "display_name": ..., "start_url": ...} — the client redirects on start_url and no password verification has occurred at all, successful or otherwise.

The known gap: no way to route by which app someone is signing into

Managing rules

The console lists every rule with its priority, name, a summary of its domain and network conditions, and where it routes to, with edit and delete actions per row. A new rule starts one priority step above the current highest. Deleting a rule is immediate, with a confirmation warning that sign-ins matching it will fall through to the next rule, or to local sign-in if none remain.

Endpoints and permission

GET     .../idp-routing-rules          iam:auth_policies:read
POST    .../idp-routing-rules          iam:auth_policies:write
PUT     .../idp-routing-rules/{id}     iam:auth_policies:write
DELETE  .../idp-routing-rules/{id}     iam:auth_policies:write

Gated on iam:auth_policies, the same permission the MFA enrolment policy and authenticator settings screens use — deciding where a sign-in is routed is treated as at least as sensitive as either.

What to do with this

1. Write your first routing rule as INACTIVE, confirm it lists the domain or network you expect in the table, then activate it — the same caution Sign-on policies and the decision trace recommends for its own rules, and for the same reason: a routing mistake here affects who can reach a password prompt at all.
2. If you need per-application routing, do not try to approximate it with domain or network conditions — flag it as a gap rather than shipping a rule that only coincidentally matches the app you meant.
3. Keep a rule's provider assignment in sync if you ever delete or recreate a federation provider; a rule pointing at a stale provider ID fails back to local sign-in silently rather than erroring loudly, so it is worth checking after any federation provider change.