Users & Roles Governance

Proper tools for governing users and roles visibility, as well as defining who can manage users and how, are essential for several security reasons.

WordPress core provides some powerful capabilities, which we'll cover later. However, AAM (Advanced Access Manager) enhances these by offering fine-tuned access controls based on user/role levels, protecting individual users from those with higher privileges.

# WordPress Core Capabilities

WordPress core includes several capabilities to manage users:

• create_users: Create new users.
• list_users: View the list of users via the "All Users" admin page or through the RESTful API.
• edit_users: Edit any user.
• delete_users: Delete any user.
• remove_users: Remove any user from a site in a multi-site setup.
• promote_users: Change any user's role.

While these capabilities are effective, they do not address scenarios such as granting admin access to freelancers, developers, or customer support agents without risking changes to your admin user, or allowing certain roles to list users without seeing high-privilege users.

This is where AAM's "Users & Role Governance" service becomes essential. Before diving into how it works, let's understand another WordPress core concept: "User Level."

# Understanding User Levels

User levels in WordPress are a legacy concept that predates the current capabilities system. In early WordPress versions, user levels (level_0 to level_10) indicated the extent of a user's permissions. Though these levels are largely obsolete now, they remain for compatibility reasons.

For instance, the Subscriber role has level_0, the Editor role has level_7, and the Administrator role has level_10.

AAM uses these user levels to help administrators set access controls for groups of users and roles. For example, you might hide users with level_7 from others or prevent privileged users from promoting others to roles with the highest user levels.

# Introduction to the UI

In AAM version 6.9.28+, the "Users & Roles Governance" tab lets you define governance rules.

By selecting "Create" in the pop-up modal, you can choose the rule type:

• Roles: Targets roles to determine their visibility. If "LIST ROLE" is set to "Deny," selected roles won't be visible, and users can't promote others to these roles.

• Roles by highest level_n capability: Targets roles based on their level to determine visibility. If "LIST ROLE" is set to "Deny," roles with the specified level are hidden.
• Users that have certain roles: Targets users with specific roles, allowing you to hide them and restrict actions like editing, deleting, or changing their passwords or roles.

• Users: Targets specific users or all users using the premium wildcard *.
• Users by highest level_n capability: Targets users based on their level to control visibility or permissible actions. This is more precise than targeting roles by level because the level_n capability can be assigned directly to a user.

# Access Policies Route

Alternatively, use AAM access policies to define rules using Role, User, RoleLevel, and UserLevel resources.

Access policies provide greater flexibility with various conditions not possible through the UI. For instance, the following policy denies listing or managing users if the current user is not in Paris, France:

{
    "Statement": {
        "Effect": "deny",
        "Resource": "User:*",
        "Action": [
            "List",
            "Edit",
            "Delete"
        ],
        "Condition": {
            "NotEquals": {
                "Operator": "AND",
                "${GEO.city}": "Paris",
                "${GEO.country_name}": "France"
            }
        }
    }
}

# RESTful API Route

Manage users and roles governance rules programmatically through AAM's RESTful API endpoints. This allows deeper integration with custom services. Refer to the "Users & Roles Governance" page for available API endpoints, or download our Postman collection for pre-made API calls.