SSO Mapping

If your users sign in through single sign-on, your identity provider already knows which teams they belong to. SSO Mapping lets GridNMS use that: you write rules that read an attribute the provider sends during sign-in and assign the user to a GridNMS group — and the group’s role decides what they can see and do.

Without a mapping rule, single sign-on proves only who someone is. Their permissions stay whatever their GridNMS account already had, so every new person needs an administrator to place them in a group by hand. With rules in place, that placement happens automatically, every time they sign in.

You’ll find it under Configure → Access Control → SSO Mapping.

What a rule looks like

Select New Rule and fill in:

Identity provider (optional) — restrict the rule to one connected provider. Leave it blank and the rule applies to a sign-in from any of them.
Attribute — the name your provider sends, such as groups, department, or a custom claim. This has to match what the provider actually asserts; check its application configuration if you’re not sure.
Match type — Exact match, Contains, or Regular expression.
Value — the value to match, interpreted according to the match type.
Assign to group — the GridNMS group a matching user is placed in.
Priority — a number that decides the order rules are checked in.
Enabled — turn a rule off without deleting it.

A rule that reads “if groups exactly matches network-admins, assign NOC Operators” is the common shape.

How rules are applied

Rules are evaluated fresh on every sign-in, against the attributes the provider asserts at that moment — not once when the account is created.

Rules are checked lowest priority number first, and the first match wins. Later rules aren’t consulted.
A match is authoritative for that sign-in: it overrides whatever group the account currently has.
If no rule matches, what happens depends on how the user’s current group was set. See below.

Because evaluation happens at sign-in, a change you make here takes effect the next time each affected person signs in — not immediately for anyone already in a session.

When a rule stops matching

Removing a rule, disabling it, editing it so it no longer matches, or the provider simply not asserting the attribute this time all lead to the same place: the user matches no rule.

If their group was assigned by a rule, GridNMS takes it back, and the account is left with no access at all — not read-only, and not the group they happened to hold before. They can still sign in; there is simply nothing they are allowed to see or do. To give them access again, assign a group by hand on the Users tab, or write a rule that covers them.
If their group was set by hand, nothing is touched. An administrator’s own assignment is never overwritten or removed by this page — including when you delete every rule.

Assigning a group by hand on the Users tab also ends rule control of that account: from then on it’s treated as hand-set, and rules will no longer change it until one matches again at a later sign-in.

What it can’t do

It can’t let anyone in. Whether an account may sign in at all is decided before mapping runs. Rules only choose which group an already-permitted user lands in.
A rule pointing at a group that no longer exists does nothing — it neither grants nor removes access. If a rule seems to be ignored, check that its group still exists.
It doesn’t create accounts. A user signs in and is mapped; GridNMS doesn’t provision people ahead of time from your directory.

Checking your work

Every change to a rule is recorded, as is every group change a rule makes — so you can see which rule moved someone and when. Search the Logs with the Include system index selected to find them.

A practical way to roll this out: write your rules with Enabled off, turn on the most specific one first, sign in as a test account, confirm the group it lands in, then enable the rest in priority order.

Next steps

docs built 2026-09-26 · 195c6d00