Access is managed on the “Users”, “Roles”, “Privileges”, “Anonymous Access”, and “Realms” pages of the “Settings” section. This page collects the operations: creating and disabling a user, assembling a role, enabling anonymous access, and changing the authentication chain. How the access model itself works is covered in Access control.
Users
The “Settings” → “Users” page. The “+ New user” button creates a local account: an identifier, name, email, password, status, and an initial role.
Statuses: “Active”, “Disabled”, and “Force password change” — the password becomes one-time: until it is changed, the user is blocked both in the web interface and in the format clients.
Switching to “Disabled” is the standard way to revoke access immediately: the user’s sessions are revoked, their token is deleted, and requests stop passing both in the web interface and in the clients (if there are several servers, on the others — with a delay of up to a minute). Switching back to “Active” restores access, but the token has to be generated anew.
Roles are assigned right in the list (the “Add role” button; the cross next to a role removes it) or in the “Edit” dialog (there the role list is set as a whole; at least one role).
Changing another user’s password (the “Change password” button) is available only with the nx-all
privilege (the admin role); the users management area privileges are not enough.
The user’s existing sessions and token keep working after the password change —
to stop the access immediately, switch the account to “Disabled”.
Roles
The “Settings” → “Roles” page. A role is assembled from privileges (by name) and nested roles; the privileges of the nested roles reach the user as well. Built-in roles are marked “read-only”.
Galleon will not let you remove the last administrator: an operation after which no active user would hold the admin role (directly or through nested roles) is rejected. The protection covers the admin role only: a custom role with the same privileges is not covered.
Privileges
The “Settings” → “Privileges” page shows the privilege catalog of the installation with a filter by type and lets you create your own with the “+ New privilege” button.
The privilege types and their fields, the actions on the content and on the repository itself, how the names are built, the restrictions on custom privileges, and the ready-made sets for the typical tasks are in Privileges.
Anonymous access
The “Settings” → “Anonymous Access” page — the global
“Enable anonymous access” switch (off by default).
What exactly is available anonymously is defined by the privileges
granted to the anonymous role (via the “Roles”/“Users” pages).
Before enabling it on a public installation, audit the privilege set of the anonymous role: every unauthenticated request runs with these rights.
Anonymous access is disabled with the same switch. The change takes effect at once; if there are several servers, on the others — with a delay of up to a minute.
Do not disable anonymous access by stripping the privileges off the anonymous role: if the role is left with neither privileges nor users, the server grants it the starter privileges anew on the next restart. Disable anonymous access only with the “Enable anonymous access” switch.
Authentication chain
The “Settings” → “Realms” page manages the composition and order of realms:
a request is checked along the chain top to bottom; the first matching realm wins.
Realms marked stub do not work yet: they reject every request.
Do not remove the cookie-session realm from the active chain — without it, signing in to the web interface becomes impossible. Saving such a configuration is blocked.