HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

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 which is a specification supported by a wide range of 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/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 synchronized from the identity provider; everything that is synchronized is visible for setting access rights by an editor.

To support assigning access rights to role claims or sending notifications to a user that is not logged in, users and roles are synchronized to the database. 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 affect the user have to login to the site again. See  Authenticate users with WS-Federation in ASP.NET Corefor more information.