groups.example.json

{
  "note": "Example group mapping. Point GROUP_MAP_FILE at a copy of this. JSON, not YAML: the keys below are OIDC group names from an external IdP, and YAML would coerce a group literally named `no`, `on`, `off` or `yes` into a boolean. `note` is the comment field JSON does not have, and it is the ONLY one -- unknown keys are a boot failure, because a typo in an authorization file must never parse silently. THE LOGIN GATE (`login_groups`) answers 'may this human use Bakery at all?', and membership in any ONE of them admits the user. LEAVE IT EMPTY OR OMIT IT TO ADMIT ANY SUCCESSFUL OIDC AUTH -- the IdP has already decided who may authenticate. That is a SEPARATE question from org membership, so `orgs` MAY BE EMPTY OR OMITTED TOO: org membership and the site role are hybrid, the groups below are only ever the OIDC half, the other half is granted in-app, and the effective role is the greater of the two. A deployment can run entirely on local grants. PROJECT roles are in-app only and must never appear here -- group-mapping them is the group explosion this design exists to escape.",

  "login_groups": ["bakery-users"],

  "site_admin_groups": ["bakery-admins"],

  "orgs": [
    {
      "slug": "acme",
      "note": "A membership justified by one of these groups is removed when the group is. A membership granted in-app SURVIVES that: the reconciler writes the OIDC columns and nothing else.",
      "groups": {
        "acme-engineering": "member",
        "acme-leads": "admin",
        "acme-directors": "owner"
      }
    },
    {
      "slug": "initech",
      "groups": {
        "initech-all": "member",
        "initech-platform": "admin"
      }
    }
  ]
}