Docs Developer Site
Enonic XP
arrow-down
  1. Manifesto
    1. Projects
    2. Build System
    1. Globals
    2. HTTP
    3. Controllers
    4. Filters
    5. Events
    6. Websocket
    7. Error handler
    8. ID provider
    9. Tasks
    10. Localization
    11. Java bridge
      1. Webapp Engine
        1. Image service
        2. Component service
      3. Admin Engine
      4. Asset service
      5. HTTP service
      6. IDprovider service
    2. Task engine
    3. Management Endpoint
    4. Statistics Endpoint
    1. NoQL syntax
    2. System properties
    3. Index configuration
    4. Aggregations
    5. Highlighting
    6. Branches
  6. IAM
    1. Widgets
    1. Schema System
    2. Mixins
    3. Input Types
    4. Content Types
    5. X-data
    6. Macros
    7. Sites
    8. Page Components
    9. Contributions
    10. Mappings
    11. Response Processors
    1. Strategies
    2. Distributions
    3. Vhosts
    4. Configuration
    5. Data management
    1. Admin API
    2. Authentication API
    3. Cluster API
    4. Common API
    5. Content API
    6. Context API
    7. Event API
    8. I18N API
    9. IO API
    10. Mail API
    11. Node API
    12. Portal API
    13. Repo API
    14. Tasks API
    15. Value API
    16. Websocket API
    1. Upgrade Notes
    2. Upgrading Apps
Enonic XP IAM

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

System ID provider login screen
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

Contents