HomeDev GuideRecipesAPI Reference
Dev GuideAPI ReferenceUser GuideLegal TermsGitHubNuGetDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Configure federated security

Describes how to configure federated security where Optimizely Content Management System (CMS) acts as a claims-aware application.

Federated security lets you separate the service a client is accessing from the associated authentication and authorization procedures, for example, to enable collaboration across multiple systems, networks, and organizations. 

This topic describes how to configure Optimizely Content Management System (CMS) and does not cover basics in federated security or how to configure ADFS.

📘

Note

Optimizely Mail and Optimizely Relate (using Common Framework), do not support federated security.

Federated security includes features such as Single-Sign-On (SSO), which allows a single-user authentication process across multiple IT systems or even organizations. The protocol used is WS-Federation, a specification supported by various federation software, such as Active Directory Federation Services (ADFS). Other federation specifications may require third-party software. In the documentation, the Relying party (RP) refers to the website running CMS. The identity server, identity provider, federation server, or Security Token Service(STS) is a third-party software such as ADFS.

In short, when authentication is required (CMS sends HTTP status code 401), a redirect sends the user to an identity provider, which, after authentication, sends back claims about the user. You can use role claims to assign access rights to content or enable access to edit view. There is no user interface to manage roles and users that CMS synchronizes from the identity provider; everything synchronized is visible for setting access rights by an editor.

CMS syncs roles and users to the database to support assigning access rights to role claims or sending notifications to users not logged in. The synchronization of users and roles is triggered when an identity provider sends back claims about a user to CMS. Users and groups are synchronized to custom CMS tables in the database when a user is authenticated (see ISynchronizingUserService in the code example below). There is no background synchronization, so for a role change to take effect, the user has to login to the site again. See  Authenticate users with WS-Federation in ASP.NET Core.