Users and Groups

Panopticon uses a very simple access control system. Users can have one or more global permissions which are applied system-wide, i.e. to all sites and all functions of Panopticon.

Users and sites can belong to zero or more user groups. This allows you to apply specific permissions to a number of sites, only applicable to specific users. You will see the (simple) mechanics of that further below.

Moreover, Groups serve a secondary purpose: they allow for site organisation. They work like tags. Wherever you see a list of sites, you can filter that list by Group (this feature was added in Panopticon 1.0.5).

Users

Users control who can log into Panopticon and what they can do. Every user can belong to zero or more Groups.

Every user can be given zero or more of the following Permissions which apply system-wide:

• Superuser. Gives access to application-level configuration pages, and automatically grants all other permissions. You need at least one User account with this permission. Try to keep the number of users with Superuser privileges to a minimum and only use them for configuration and maintenance of the system.
• Administration. Allows editing the configuration of a Site.
• View. Allows viewing the Site Overview page of a Site.
• Execute. Allows executing actions (scheduling updates, taking backups, …) on a Site.
• Add Own. Allows adding new sites, owned by the User. The user will need to have the View or Edit Own privilege to view the Site Overview page of their own sites. The user will need to have Administration or Edit Own privilege to edit their own sites. The user will need the Execute or Edit Own privilege to execute actions on their own sites.
• Edit Own. Grants the user the Administration, View, and Execute privileges only on sites which are owned by the user, i.e. sites where the Created By matches this user.

To create self-service users, grant them the Add Own and Edit Own privileges.

ℹ️ Bear in mind that adding a site means telling Akeeba Panopticon to make a request to a URL of the user's choosing, from your server, and show them the result. If the users you grant Add Own to are not people you trust — for example, if they are clients who pay you for monitoring — you should also review the Forbidden IP Ranges and Connection Doctor access options described in System Configuration, so that they cannot point your server at your own internal network and read what comes back. That page also explains, under “A block list is always observable”, what such users can and cannot infer about your network whatever you configure, so that you can make an informed decision about whether this use case suits you at all.

Remember that privileges granted to a user account (“global privileges”) override the privileges granted to a user by their Groups membership (“group privileges”).

Think of permissions as keys. If you have the key, you get access. It doesn't matter if you have a regular key (group privilege) or a skeleton key (global privilege); you can unlock that lock.

Groups

Groups only carry a name and zero or more of the following permissions:

• View
• Execute
• Administration

These are the same permissions as the ones you saw for each User. However, they do NOT apply across all sites. They only apply to the sites which belong to that Group, as long as the user trying to access that site also belongs in that Group.

The idea is that Group privileges grant users privileges they don't have at the User (global) level, for specific sites. This allows you for fine-grained control of site access.

Advanced access control

It's easier to understand how to put everything together with an example.

We have four users:

• root with the Superuser privilege selected. Does not belong to any Group.
• secretary with no privilege selected. Belongs to the Secretarial group.
• operator with no privilege selected. Belongs to the Operators group.
• admin with no privilege selected. Belongs to the Secretarial, Operators, and Admins group.

We have three groups:

• Secretarial with the View privilege selected.
• Operators with the Execute privilege selected.
• Admins with the Administration privilege selected.

We have two sites:

• Main Site, belongs to the Secretarial, Operators, and Admins group.
• Super Secret Site, does not belong to any group.

The root user can view both sites. They can also edit these sites' configurations, and execute updates on them.

The admin user can only see the Main Site. They can also edit this one site's configuration, and execute updates on it.

The operator user can only see the Main Site. They can also execute updates on it, but not edit its configuration.

The secretary user can only see the Main Site. They can neither edit its configuration, nor execute updates on it.

Your takeaway: By creating appropriate groups and assigning them to your users and sites, you can give your clients' staff access to the Panopticon pages for their sites. You are not exposing your other clients' sites to them - Panopticon remains mum about these other sites to these users. By varying the per-group privileges you can prevent your clients from carrying out potentially problematic operations on their sites in Panopticon.

User Registration

Panopticon supports optional self-registration, allowing new users to create their own accounts from the login page. Two registration modes are available: Admin Approval (administrator must review and approve each account) and Self-Approval (users activate via email). Registration includes CAPTCHA protection, forbidden username blocking, email domain restrictions, and password complexity enforcement.

For full details see the User Registration page. Registration is configured in the Registration section of System Configuration.