Identity and access management (IAM)
Contents
Identity and access management (IAM)
Enonic XP ships with a clearly defined and pluggable concept for handling authentication and authorization
Introduction
Enonic XP ships with a standard concept handling users, authentication, groups and roles based authorization. Additionally, the NoSQL storage supports fine-grained access control mechanisms down to a single item.
IAM Concepts
XP AIM consists of three central concepts:
Principals
Principals are object that can be given permissions. There are three different types of principals:
- Users
-
Principals that can be authenticated.
- Groups
-
Used to group other principals to simplify management.
- Roles
-
Provides access to application specific functionality.
Permissions
Principals may be given with fine grade access to items stored in the NoSQL storage. An example of this is the XP CMS, where users typically get access to create or publish content in specific areas of the solution.
Identity providers
ID providers offer pluggable abstraction layer for user authentication. As such, in order to authenticate or even create users in XP, you will need to define an ID provider.
IDproviders are linked to your webapp or site through virtual hosts.
Creating an ID provider
IDproviders can be created and managed through the API, or through the Users app in the XP admin console.
An idprovider essentially consist of the following:
-
A unique name (cannot be changed later)
-
ID provider application, with optional configuration settings.
-
Permissions - specifies who can manage and access the ID provider
ID provider applications must be installed before you can select them. |

System ID provider
XP ships with a special ID provider that cannot be removed or renamed. It is called the system
ID provider.
The purpose of the system ID provider is to hold system users such as su
- the Super User, and anonymous
- the user that is defacto if no other user is specified.
When accessing the XP admin console for the first time in a fresh installation, you will see the system IDprovider.

Avoid placing your regular users in the system ID provider, rather create a new ID provider instead. |
IDprovider apps
In order for an ID provider to work, it must be associated with an ID provider application that handles the authentication process.
You may install ID providers from Enonic Market, or build your own for a fully customized experience.
Standard ID provider app
By default, XP ships with an app app called the "Standard ID provider". This is also the app that is being used by the System ID provider
Built-in roles
Enonic XP is shipped with several built-in roles (described below) which grant certain permissions when applied to users. New roles can be created by users with Administrators and Users Administrator roles.
Permissions for every role can be overridden by Administrator or Content Manager Administrator on the content level. |
Administrator Users with the Administrator role have full access to all content and admin tools through the user interface.
Administration Console Login Users with this role can log in to the administration console. These users will also require a role for each of the admin tools that the users need access to.
Content Manager App
This role allows users to access Content Studio. Users with this role can see content and sites, but cannot create new sites or any new content in the project root.
Content Manager Expert
This role is similar to Content Manager App but can also access and modify source code inside HTML area and text components on pages.
Content Manager Administrator
This role allows full access to Content Studio, as well as being able to change content permissions.
Users App
This role allows view-only access to the Users admin tool.
Users Administrator
This role allows full access to the Users admin tool, including create/edit/delete for Id providers, users, roles, and groups.
Authenticated
Users automatically have this role when they are logged into the system in any way.
Everyone
This is a special role that any user/site visitor - authenticated or not - will always have. This role is typically used to grant read permissions to publicly available content.
NOTE: If you are using Content Projects, your project will have a set of project-specific roles in addition to the built-in ones.