Advanced Access Manager (aka AAM) is the WordPress plugin that has a set of tools to manage access to website resources like backend menu, posts, pages, categories, etc. It is the top 1% of the most popular plugins in the Official WordPress Repository and can be downloaded for free at any time. However, some of the features are available only with premium add-ons.
WordPress security and access controls are probably the most challenging tasks because WordPress CMS (Content Management System) was never designed to hide/protect anything. That is why AAM becomes so valuable for website administrators. It allows managing access to your website for any role, individual user, visitors or everybody at once.
By default, AAM is available only for users with the Administrator role and when navigating to the AAM page, you should be able to see something similar to what is shown on the screenshot below. You can learn more about the AAM page from the plugin reference page on the “AAM UI Interface” section.
FYI! You have the ability to define granular access to all the AAM features and grant access for none-administrator users to desired functional aspects of the plugin. For more information, refer to the “How to manage access to AAM page for other users” article.
At first, it might be overwhelming looking on the AAM page, however, the full picture will get much more clear when you learn a few core AAM concepts listed below.
WordPress is the collection of resources
Everything in the WordPress CMS can be considered as a resource that somebody is trying to access or change. For example, the backend menu consists of menus and sub-menu items; any frontend menu is the collection of posts, pages, custom links or categories; media attachments in the Media Library or post tags on the “Posts->Tags” page. All the mentioned things are more are individual resources that you have the ability to manage access to and that is where AAM comes in play and helps you to define granular access rules.
The “Main Panel” is the place where you can find the list of all available services that AAM offers to manage access to a different type of resources like backend menu, metaboxes & widgets or posts & terms.
AAM comes with two types of services: those that manage access to the WordPress resources (post, pages, widgets, capabilities, etc.) and others that manage various options (login redirect, 404 redirects, access denied redirect, etc.)
Resources are accessible by somebody
It makes no sense to have resources if they are not designed to be accessed by somebody. It can be either a user or programmatic application. We call them subjects or somebody/something that perform certain actions upon resources and WordPress core defines two types of subjects: users and roles.
On top of that AAM introduces also two other types of subjects: visitors are users that do not have an identity (unauthenticated users) and default subject from which all users, roles and visitors inherit access settings. This way you have no limits defining access settings the way you need it.
AAM Users/Roles Manager Panel is the place where you can navigate between different types of subjects. Each time you select any particular roles, user, visitors or default, the entire AAM “Main Panel” reloads and allows you to define access settings for the selected subject.
Under the hood, AAM automatically propagates all the settings, down the hierarchical chain to the user or visitor.
Everything in the WordPress core is connected
From the above, you already learned that a WordPress website is the collection of resources and subjects that request access to them. Now it is time to learn that they all are related to each other one way or another. For example, a page can have a parent page, a post always has an author that is technically a user that has a parent role or multiple roles. It is important to understand the nature of those relationships to properly propagate access settings and some of them are extremely complex.
Luckily AAM comes with a one-of-a-kind access settings inheritance mechanism that takes into consideration all known WordPress core relationships between website resources, users and roles. This opens infinite possibilities to define access and security controls your way without compromising a website performance. You can scale your website to hundreds of thousands of users or millions of posts and AAM can handle them all.
To learn more about AAM access setting inheritance mechanism, refer to the “AAM Access Settings Inheritance Mechanism” article. Only by mastering this core AAM concept, you will discover the true power of this plugin.
Access control can be an artifact
While the vast majority of website administrators can be fully satisfied with AAM UI and flexibility that it offers. Those individuals and companies that take access management to the next level, know that any UI will be limited to the most common use-cases and it is really easy to make a human-error while managing access. Even if AAM will offer a fully-blown monitoring tool that tracks all the changes to the access settings, it still will not capture the intent for the changes.
FYI! Indeed, while AAM UI is comprehensive and complex, it is still limited to the most common use-cases and we are very resistant to adding new UI elements to avoid overwhelming interface with options.
We quickly realized that it would not be possible to give powerful, flexible and at the same time cohesive framework just with AAM UI. That is why in AAM 5.7.0 and higher, we’ve introduced the concept of Access Policies. It is a JSON-based document that allows you to define access settings to any WordPress resources and with the power of Conditions, you basically have no limit defining access triggers based on any condition (e.g. restrict access to the backend area for anybody if it is Sunday or redirect visitor to the login page if she comes from South America).
To simplify the administrative work, we even launched the Access Policy Hub where you can find ready-to-use access policies for the most requested use-cases.
Try! The “Private WordPress Website” policy makes your website completely private and redirects all visitors to the login page.
Because each access policy is a separate post type, any changes to a policy are stored as revisions and you can track what was changed and by who.