Admin Site

The admin site allows administrators to configure, manage and troubleshoot Alliance Auth and all its applications and services. E.g., you can create new groups and assign groups to users.

You can open the admin site by clicking on “Admin” in the drop-down menu for a user that has access.

Admin Site

Setup for small to medium size installations

For small to medium size alliances, it is often sufficient to have no more than two superuser admins (admins that also are superusers). Having two admins usually makes sense, so you can have one primary and one backup.

Warning

Superusers have read & write access to everything on your AA installation. Superuser also automatically have all permissions and therefore access to all features of your apps. Therefore, we recommend to be very careful to whom you give superuser privileges.

Setup for large installations

For large alliances and coalitions, you may want to have a couple of administrators to be able to distribute and handle the work load. However, having a larger number of superusers may be a security concern.

As an alternative to superusers admins, you can define staff admins. Staff admins can perform most of the daily admin work, but are not superusers and therefore can be restricted in what they can access.

To create a staff admin, you need to do two things:

Enable the is_staff property for a user
Give the user permissions for admin tasks

Note

Note that staff admins have the following limitations:

Cannot promote users to staff
Cannot promote users to superuser
Cannot add/remove permissions for users, groups and states

These limitations exist to prevent staff admins from promoting themselves to quasi superusers. Only superusers can perform these actions.

Staff property

Access to the admin site is restricted. Users need to have the is_staff property to be able to open the site at all. The superuser created during the installation process will automatically have access to the admin site.

Hint

Without any permissions, a “staff user” can open the admin site, but can neither view nor edit anything except for viewing the list of permissions.

Permissions for common admin tasks

Here is a list of permissions a staff admin would need to perform some common admin tasks:

Edit users

auth | user | Can view user
auth | user | Can change user
authentication | user | Can view user
authentication | user | Can change user
authentication | user profile | Can change profile

Delete users

auth | user | Can view user
auth | user | Can delete user
authentication | user | Can delete user
authentication | user profile | Can delete user profile

Add & edit states

authentication | state | Can add state
authentication | state | Can change state
authentication | state | Can view state

Delete states

authentication | state | Can delete state
authentication | state | Can view state

Add & edit groups

auth | group | Can add group
auth | group | Can change group
auth | group | Can view group
authentication | group | Can add group
authentication | group | Can change group
authentication | group | Can view group

Delete groups

auth | group | Can delete group
authentication | group | Can delete group

Permissions for other apps

The permission a staff admin needs to perform tasks for other applications depends on how the applications are configured. The default is to have four permissions (change, delete, edit view) for each model of the applications. The view permission is usually required to see the model list on the admin site, and the other three permissions are required to perform the respective action to an object of that model. However, an app developer can choose to define permissions differently.