Users, roles & permissions

Access control in MintJams CMS is built from users, groups and roles (principals) and the ACLs granted on nodes. Identity is managed globally in the system workspace and shared across all workspaces.

Two ways to manage it

Method Use it for
Identity Manager (app) interactive management from the UI; day-to-day creation, edits, passwords
Provisioning (YAML) declarative, reproducible seeding; the initial set shipped with an app

Both write to the same model, so the accounts they create are indistinguishable. See "Identity Manager" and "Provisioning".

Principals

  • Users — /home/users/{id}. Accounts that can sign in interactively
  • Groups — /home/groups/{id}. Bundle members and serve as the unit of permission grants
  • Roles — /home/roles/{id}. Bundles of permissions
  • Service accounts — non-interactive identities with no password, used by integrations via runAs; they cannot sign in

Groups and roles can be hierarchical. Membership has both direct and effective (including ancestors) forms.

Permissions (ACL)

On each node, grant a principal allow or deny for a set of privileges.

acl:
  - group: commerce-operators
    privileges: jcr:read, jcr:write
    effect: allow
  - user: anonymous
    privileges: [jcr:all]
    effect: deny
  • the grantee is exactly one of group / user / principal
  • privileges are JCR privileges such as jcr:read, jcr:write, jcr:all
  • effect is allow or deny

ACLs can be set from the Content Browser Inspector (permissions) or from provisioning nodes.

Operational tips

  • Give a service account access by adding it to a normal group and granting that group on the relevant nodes.
  • Change or reset passwords in Identity Manager (provisioning never changes an existing password).
  • Authentication is based on SAML 2.0 (SP / IdP bundled with zero configuration).