Identity and access management (IAM)

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 IAM 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.

Setting up an ID provider from the Users admin tool

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.