Skip to content

Groups

You want to grant access to a role rather than to each person in turn. On AWS that is an IAM group. Here it is a group in your identity domain, and it works the same way: grant once, to the group, instead of repeatedly to individuals.

Prerequisites

The step-by-step guide and the console walkthrough cover the operations. The rest of this page explains how it fits together.

Create the groups before the users

Groups have to exist before users can be assigned to them.

flowchart LR
    subgraph BAD["users first"]
        direction TB
        U2["create users"] --> G2["create groups"]
        G2 --> E2["edit every user<br/>to add membership"]
    end
    subgraph GOOD["groups first"]
        direction TB
        G1["create groups"] --> U1["create user<br/>tick its groups on the form"]
        U1 --> D1["done - one step per person"]
    end

The user form lets you tick the groups a new person belongs to. If the groups already exist, membership is one tick each. If they do not, it becomes a separate edit per person later.

Membership lives on the user, not on the group

There is no member list on a group. A user object carries the groups it belongs to, so changing who is in a group means editing those users - see Users.

Name them for the role, not the permission

support survives a reorganisation. can-read-billing-db stops being true the moment the permission changes, and then the name actively misleads.

Nesting inherits downwards

A group can sit under another. A child inherits everything the parent has.

flowchart TB
    STAFF["staff<br/>everyone gets this"]
    SUP["support"]
    ENG["engineering"]
    STAFF --> SUP
    STAFF --> ENG
    NOTE["members of support get<br/>support + everything staff has"]
    SUP -.- NOTE

That is useful - grant something to everyone once, keep the narrower groups for what only they should reach.

Nesting grants the parent group's access to every member

Putting a narrow group under a broad one gives its members everything the broad group holds, which is rarely what was intended.

If you are not sure, choose no parent. A top-level group can always be granted the same things explicitly, and it cannot leak access it was never given. The parent cannot be changed afterwards - a group in the wrong place has to be recreated.

What can change

The description, and nothing else. The name, the realm and the parent are all fixed at creation.