MANAGE GROUPS
This guide shows you how to organize users into groups and grant access by group instead of managing individual grants.
Create a group
swamp access group create release-managers --server wss://swamp.example.comAdd members to a group
swamp access group add-member release-managers user:sarah \
--server wss://swamp.example.com
swamp access group add-member release-managers user:adam \
--server wss://swamp.example.comGrant access to a group
Use group:<name> as the subject:
swamp access grant create --subject group:release-managers --allow run \
--on 'workflow:*' --server wss://swamp.example.comAll members of release-managers inherit this grant. When a new user is added
to the group, they gain the same access after the next policy reload.
List groups
swamp access group list --server wss://swamp.example.comList members of a group
swamp access group members release-managers --server wss://swamp.example.comRemove a member
swamp access group remove-member release-managers user:adam \
--server wss://swamp.example.comAfter removing a member, reload the policy snapshot for the change to take
effect (unless using --grant-reload auto).
Subject types
Grants accept three kinds of subjects:
| Subject format | Matches |
|---|---|
user:<id> |
A specific authenticated user |
group:<name> |
Members of a local group |
idp-group:<collective-slug> |
Users whose IdP token includes the group |
Local groups are managed with swamp access group. IdP groups come from the
OAuth provider's userinfo response and are refreshed periodically — see the
authorization reference
for how group refresh and deprovisioning work.
To see which IdP groups the server has observed from authenticated users, run:
swamp access group list-idp --server wss://swamp.example.comThis is useful for verifying that your identity provider's group claims are
arriving as expected and for debugging idp-group: grant matching. See the
access commands reference
for full details.
If that list is missing a group you expect, the question is whether Swamp ever received it. Ask your Swamp administrator to check the operative's IdP group diagnostics, which record what each SSO sign-in's assertion carried — so a group claim that arrived and one that was never sent are distinguishable, rather than both showing up as no groups. Note also that for SAML federation groups are only re-read at sign-in; see refresh does not apply to SAML federation.
Related
- Manage Access Grants — create and revoke grants
- Real-World Scenarios — team isolation using groups