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.

Non-interactive execution and runAs

Execution contexts that have no interactive sign-in run as anonymous (guest) by default. For example:

  • Public endpoints under /content/public (reachable unauthenticated)
  • Service tasks, task listeners and execution listeners run by the BPM engine (the engine thread carries no user identity)
  • EIP timer-fired routes and other work not tied to a request

Anonymous cannot read protected resources whose ACL denies anonymous — such as /etc/... configuration that holds integration secrets, or server-side integration scripts. When such work touches a protected resource it fails with AccessDenied, unable to read even the configuration or script itself.

The fix is to run as a service account (runAs). How you specify it depends on the execution context:

Execution context How to set runAs
BPM (service task / task & execution listeners) Set the service-account name in the CmsDelegate runAs field
EIP (steps such as cms: scripts) Set the runAs header (typically via a dedicated privileged direct: route)
Public endpoint Don't read secrets directly; delegate to a privileged direct: route and receive only the result (the verdict)

Keep the public endpoint itself anonymous (least privilege) and isolate secret reads and signature verification in a service-account privileged route.

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).