Docs Developer Site
Enonic XP
arrow-down
    1. Overview
    2. Core concepts
    3. Using docs
    4. Intro Videos
    5. Tutorials
    1. Intro
    2. GraphQL API
    3. Media API
    4. Extending the API
    5. Component API
    1. Content Studio
      1. Branches
    3. Layers
      1. Lifecycle
      2. Media
      3. Attachments
      4. X-data
        1. Page templates
        2. Fragments
      6. Variants
      7. Permissions
      8. Versions
    5. Sites
      1. Visual editor
    7. Publishing
    1. Introduction
      1. Controllers
      2. Globals
      3. Events
      4. HTTP Request
      5. HTTP Response
      6. Error handler
      7. Filters
      8. Templating
      9. Localization
      10. Websocket
      11. Tasks
      12. Main controller
      13. Java bridge
      1. Admin Lib
      2. Application Lib
      3. Auditlog Lib
      4. Authentication Lib
      5. Cluster Lib
      6. Common Lib
      7. Content Lib
      8. Context Lib
      9. Event Lib
      10. Export Lib
      11. Grid Lib
      12. I18N Lib
      13. IO Lib
      14. Mail Lib
      15. Node Lib
      16. Portal Lib
      17. Project Lib
      18. Repo Lib
      19. Scheduler Lib
      20. Schema Lib
      21. Tasks Lib
      22. Value Lib
      23. VHost Lib
      24. Websocket Lib
    4. Other Libraries
      1. CLI
      2. Sandboxes
      3. Code
      4. Building
      5. Configuration
      6. TypeScript
    6. Building APIs
      1. Mappings
      2. Components
      3. Processors
      4. Contributions
    8. Building Webapps
      1. ID providers
      2. Admin Apps
      3. Admin Widgets
    1. Architecture
      1. TODO
      1. Navigating
      2. Users
      3. Applications
      4. Data management
      5. System info
      6. Audit Logs
      7. Task management
      1. Portal
      2. IDprovider
      3. Management
      4. Statistics
      1. Nodes and repos
      2. Properties
      3. Indexing
      4. Branches
      5. Editors
      1. DSL Queries
      2. NoQL Queries
      3. Filters
      4. Aggregations
      5. Highlighting
      1. ID providers
      2. System ID provider
      3. Users and groups
      4. Roles
      1. Strategies
      2. Distributions
      3. Docker
      4. Kubernetes
      5. Systemd
      6. Vhosts
      7. Configuration
      8. Backup & restore
      9. Clustering
      10. Observability
      1. Notes
      2. Upgrade
      3. Upgrading Apps
        1. Asset service
        2. HTTP service
        3. Image service
    1. Best practice
        1. AttachmentUploader
        2. Checkbox
        3. Combobox
        4. ContentSelector
        5. ContentTypeFilter
        6. CustomSelector
        7. Date
        8. DateTime
        9. Double
        10. GeoPoint
        11. HtmlArea
        12. ImageSelector
        13. Long
        14. MediaSelector
        15. Radiobutton
        16. Tag
        17. TextArea
        18. TextLine
        19. Time
        1. Field set
        2. Item set
        3. Option set
      3. Mixins
      4. Localization
      5. Styles
    3. Content Types
    4. X-data
    5. Macros
      1. Pages
      2. Regions
      3. Part component
      4. Layout component
      5. Text component
      6. Component Filtering
      7. Component Indexing
    1. Marketplace
    2. Market guidelines
Developer Docs Xp Next Iam System Idp

System ID provider

Contents

Introduction

XP ships with a special ID provider that cannot be removed or renamed. It is called the System ID provider.

Built-in

When accessing the XP admin console for the first time in a fresh installation, you will see the login screen of System ID provider.

System ID provider login screen

System users

The System ID provider also contains some special users:

The Super User

system:su The Super User exists in order to perform priveliged actions, and to allow you to start using XP before you have created any users. The Super User has the system.admin role, and thus unrestricted access.

system:anonymous - XP expects a user in every request. As such, the Anonymous user steps in to cover for users that have not authenticated.

Service Accounts

Unlike other ID providers, the users in the System IDP are referred to as service accounts.

Service accounts are designed for machine-to-machine authentication from remote clients to XP.

Avoid adding human users to the System ID provider, rather create a new ID provider for this purpose.

Since service accounts also are regular XP users, you may grant them roles and permissions as needed.

Service accounts users can be recognized from the small cog symbol above their avatar in the top right.

Service Account Key

A Service Account may be associated with one, or several Service Account keys. Using a Service Account Key is beneficial for security reasons:

  • It allows to authenticate without transferring the password over the network.

  • Support for multiple keys allow rotation of Public-Private key-pairs without service interruption.

  • Stored Public key is not a hash of a password, so it is not possible to reverse-engineer the password from the public key.

Once a key is created, it may be used to make an authorized call to:

List of service account keys
Service account keys are a security risk if not managed correctly. Make sure to rotate keys regularly and keep them safe. If you suspect that your keys have been compromised, you can revoke them in the Users app. Also consider using ID providers that support 3-leg authentication, such as the OIDC ID provider, if possible.

Generate key

You may easily generate new keys by clicking add. Simply give your key a name, and click btn:generate.

Generate service account key
The public key will be saved, and the private key will automatically be downloaded to your device (in JSON format).

Upload key

You may also upload the public key portion of a user-managed key pair, and the use the private key for authenication later.

The key you upload must be an RSA public key and encoded in base64. You can use tools such as OpenSSL to generate a key and certificate in this format.

Try it out The following command generates a 2048-bit RSA key pair

openssl genpkey -algorithm RSA -out xp_private_key.pem -pkeyopt rsa_keygen_bits:2048 && \
openssl rsa -pubout -in xp_private_key.pem -out xp_public_key.pem

After generating the key, you may upload the public_key.pem file to your service account.

Upload public key

JWT authentication

XP enforces short-lived tokens. You may change the default timeout of 30 seconds in the ID provider configuration.

The System ID providers supports JWT (JSON Web Token) based authentication via the HTTP Authorization header.

The header should look like the following:

Authorization: Bearer <mytoken>

The JWT token must be a valid RFC-7519 JWT token, following these requirements:

  • alg header parameter must be set to RS256.

  • kid header parameter must be set to ID of the public key that corresponds to the private key used to sign the token.

  • sub claim must be set to ID of the service account, for instance, user:system:myuser.

  • exp claim must be set to expiration time of the token. The token will be rejected if it is expired.

  • iat claim must be set to issue time of the token. The token will be rejected if it was issued in the future.

JWT header example
{
  "kid": "51a29c2ab5ebf945f6a5ddac8935bf8b",
  "typ": "JWT",
  "alg": "RS256"
}
JWT payload example
{
  "sub": "user:system:myuser",
  "exp": 1692787396,
  "iat": 1692787366
}

We recommend using libraries that match your client platform to generate the token - especially related to the requirement for short lived tokens.

  • The private key from the Public-Private key pair should only be stored on the client side to generate the token, and never shared with the XP server.

  • The public key from Public-Private key pair is only stored in XP, and used to verify the signature of your token.

Contents

Contents

AI-powered search

Juke AI