Optimizely (Episerver) User Management | OpsBlu Docs

Optimizely (Episerver) User Management

Manage users, roles, and access rights in Optimizely CMS (formerly Episerver). Covers the ASP.NET membership system, virtual roles, content access...

Optimizely CMS (formerly Episerver) uses a role-based access control system built on the ASP.NET Identity framework. Permissions operate at two levels: system-level roles that control access to admin and editorial features, and content-level access rights that control who can read, edit, publish, and administer individual pages and content trees.

Permission model overview

Optimizely CMS structures access through:

  • Users -- Accounts authenticated via ASP.NET Identity, Active Directory, or a configured identity provider
  • Roles/Groups -- Named collections of users. Roles grant access to system features (admin mode, edit mode) and are used to set content access rights.
  • Virtual Roles -- Dynamically evaluated roles based on conditions (e.g., "Everyone," "Authenticated," "Anonymous," "Creator"). These are defined in code and cannot be managed through the admin UI.
  • Access Rights -- Per-content-node permissions (Read, Create, Change, Delete, Publish, Administer) assigned to roles or individual users

Key built-in roles

  • Administrators -- Full access to all CMS functionality: admin mode, edit mode, visitor groups, content deployment, and all settings. Maps to the ASP.NET Administrators role.
  • CmsAdmins -- Access to CMS-specific administration: manage content types, scheduled jobs, tool settings, and languages. Does not include Commerce or other product admin areas.
  • CmsEditors -- Access to the editorial interface (edit mode). Can create, edit, and publish content based on content-level access rights.
  • WebAdmins -- Full access to all Optimizely products (CMS, Commerce, Find, etc.). Broader than CmsAdmins.
  • VisitorGroupAdmins -- Can create and manage visitor groups used for personalization and A/B targeting.
  • SearchAdmins (if Optimizely Search & Navigation is installed) -- Manage search configuration, boosting rules, and synonyms.

Additional roles are created through the admin interface or identity provider.

Content access rights

Content access rights are set per-page or per-content-area and inherited down the content tree. Each access right entry specifies a role (or user) and which permissions they have:

  • Read -- View the content in edit mode and on the published site
  • Create -- Create child pages or content under this node
  • Change -- Edit the content properties and blocks
  • Delete -- Remove the content
  • Publish -- Transition content from draft/review to published state
  • Administer -- Modify the access rights on this content node (effectively a local admin)

Access rights are managed via the Set Access Rights dialog on any content node in edit mode, or under Admin > Set Access Rights for the entire content tree.

Rights are inherited by default. A page inherits its parent's access rights unless explicitly overridden. Breaking inheritance creates an independent ACL for that node.

Admin UI paths

  • Admin Mode -- /EPiServer/CMS/admin -- System administration for content types, scheduled jobs, languages, property definitions, and tool settings
  • User management -- Depends on identity provider:
    • ASP.NET Identity -- /EPiServer/CMS/admin/ > Users and Groups tabs for managing local accounts and role assignments
    • Active Directory / Azure AD -- Users are managed in the external directory; role mapping is configured in Optimizely via group synchronization
  • Access Rights -- Admin > Set Access Rights (/EPiServer/CMS/admin/setaccess.aspx) for tree-wide management, or right-click a page in edit mode > Set Access Rights for per-node configuration
  • Visitor Groups -- CMS > Visitor Groups for personalization segment management

Managing users

With local ASP.NET Identity:

  1. Navigate to Admin > Users > Create User
  2. Enter username, email, and password
  3. Assign the user to one or more roles (CmsEditors, CmsAdmins, etc.)
  4. Save -- the user can log in immediately

With Active Directory / Azure AD:

  1. Users are created in the external directory
  2. AD groups are mapped to Optimizely roles in the web.config or Startup configuration via AddCmsAspNetIdentity or OWIN middleware
  3. When a user logs in via SSO, they are automatically assigned roles based on their AD group membership

Removing a user:

  1. For local accounts: Admin > Users > delete or deactivate
  2. For AD-based accounts: disable in Active Directory; the user loses CMS access on next login attempt
  3. Review content ownership -- reassign pages owned by the departing user

API and integration access

  • Content Delivery API -- Read-only headless API for published content. Authenticated via API keys or OAuth tokens. Configure under Admin > Content Delivery API settings.
  • Content Management API -- CRUD operations on content. Uses OAuth 2.0 with tokens scoped to the user's permissions.
  • Service API (Commerce) -- RESTful API for Commerce operations. Requires a service account with appropriate roles.
  • Integration API -- For scheduled imports and data synchronization. Typically runs under a service account with CmsAdmins or equivalent role.

API tokens inherit the permissions of the associated user or service account. Create dedicated service accounts with minimal roles for integrations.

Analytics and experimentation permissions

Optimizely is uniquely positioned as both a CMS and an experimentation platform:

  • Optimizely Web Experimentation / Feature Experimentation -- Managed in the Optimizely application (app.optimizely.com). Users need an Optimizely account with project-level permissions (Viewer, Editor, Project Owner) separate from CMS roles.
  • Analytics dashboard -- If Optimizely Data Platform (ODP) or Optimizely Analytics is configured, access is controlled through the Optimizely application, not the CMS admin.
  • Tracking script installation -- The Optimizely snippet is typically added to the site's master layout template. Modifying templates requires developer access to the codebase or CmsAdmins role to edit container pages.
  • Google Analytics / GTM -- Implemented in layout templates or via a custom add-on. Requires developer or template-admin access.
  • Visitor Groups -- Creating personalization segments that drive analytics requires the VisitorGroupAdmins role.
  • A/B testing in CMS -- The built-in A/B testing feature for content requires CmsEditors role with Publish permission on the tested content.

Content editors can run A/B tests on their own content but cannot install tracking scripts or configure external analytics integrations.

Security and SSO

  • Azure AD / OpenID Connect is the standard SSO integration for Optimizely DXP (cloud)
  • ADFS / SAML 2.0 is supported for on-premise deployments
  • Mixed-mode authentication allows some users to authenticate locally while others use SSO
  • MFA is configured at the identity provider level (Azure AD Conditional Access, ADFS policies)
  • Audit logging for content changes is available through the content version history. Administrative actions are logged in the event log.

Further Reading

Back to top