Skip to main content

Groups

Granting access one person at a time does not scale. Groups solve that: a group is a named set of people, and a grant can be given to a group exactly as it is given to a person. Grant Reader to the group Analysts at a scope, and every member of Analysts reads there — add or remove a member and their access follows automatically.

Internal groups are the primary tool​

iontos manages its own groups: you name them, decide who is in them, and administer them through iontos. Internal groups always work, for every deployment, no matter what identity system you use. They are the main mechanism, not a fallback — most access is best expressed as "these roles, for this group, at this scope."

Driving membership from your own directory​

If your organization prefers to keep all access decisions in its own identity system, you can map your directory's groups onto iontos groups. Your directory reports which groups a person belongs to when they sign in; iontos translates those into membership of the matching internal groups.

  • The mapping lives on the iontos side, so your directory's naming conventions stay entirely on your side — nothing about iontos needs to be configured in your identity system.
  • A mapping is always tied to the specific identity system it came from, so one organization's group names can never accidentally satisfy another's. Your "Analysts" and another company's "Analysts" are never confused.
  • Directory-driven membership is refreshed whenever a person signs in, so it tracks changes you make in your own system.

Whichever way membership is set, the effect is identical: grants attach to the group, and members inherit them.

Exclusions​

Occasionally a directory says something you cannot correct in time — a person is in a group they should not be, and fixing the source will take weeks. For that case, an administrator can exclude a specific person from a directory-driven group.

An exclusion masks that person's directory-sourced membership when access is worked out; it does not delete anything and does not touch your directory. It is recorded in the audit trail, so the reason a person does or does not have access is always traceable. (An exclusion only overrides directory-sourced membership — if you have also added the person to the group directly inside iontos, that deliberate choice stands.)

Putting it together: effective access​

A person's effective access is simply:

every grant given to them directly + every grant given to any group they belong to − anything an exclusion masks.

Membership can come from inside iontos or from your directory; access is worked out the same way regardless of how someone came to be in a group.

When a group is "too coarse"​

There are no negative grants (see Grants) — you cannot give a group a set of roles and then subtract one for a particular member. If some members should hold fewer of a group's roles than others, that is a sign the group is drawn too broadly: split it into finer groups, or exclude the person and place a smaller compensating grant. Keeping subtraction to whole-group membership is what keeps "what can this person do?" answerable at a glance.