Skip to main content

Install ADFS Server and Relying Party

In the next series of blog posts, I am writing about securing SDL Web 8.5 (on-premise installation) against an Active Directory, through an ADFS (Active Directory Federation Service) server.

The goal is to have SDL Web 8.5 CME (the GUI) authenticate agains the ADFS server and also to have all web services that come with SDL Web authenticate against the same ADFS. Our setup is to have SDL Web in the cloud (AWS), connecting to an AD in a data center. The authentication with AD is exposed through some ADFS endpoints.

I installed the ADFS server using all default settings. What I'm focusing on in this post, is the creation of a Relying Party (or an application) that can request authentication tokens from the ADFS server.

The ADFS server is used in 2 modes:
  • passive authentication: a browser is redirected to ADFS to authenticate, then the browser is redirected back to the application with the authentication token in a header or POST body;
  • active authentication: a client calls ADFS directly with username/password to get the authentication token, then passes the token to the service it calls;
I will use ADFS passive authentication for the SDL Web CME and ADFS active authentication for the SDL Web web-services such as CoreService, TemplateUpload service, Workflow service, WebDAV connector, ImportExport service, etc.

The ADFS properties is presented in the screenshot below. We are going to use the Federation Service Identifier for our passive authentication method.

In ADFS, I create a Relying Party (the SDL Web Tridion application) running on server web85.playground. This is the remote application that is allowed to connect and authenticate with the ADFS server.

The Relying Party can use both active and passive authentication against the ADFS. The communication between SDL Web and ADFS is done over HTTPS. In the following screen, we define some "Relying party identifiers", which are simply some logical names in the format of a URL that identify the remote application requesting tokens from ADFS:

The token issued by ADFS is in SAML format, using SSL encryption for the sensitive information inside it (e.g. user account, user roles). The following screen defines the certificate with the public key the ADFS server uses when it encrypts SAML tokens to be sent back to the Relying Party (i.e. Tridion application). On the Tridion application (web85.playground server) there must installed the same certificate with private key in order to be able to decrypt the SAML token:

In the following screen, we define the "post back URL" on the SDL Web server that the ADFS server calls when posting back the token in passive authentication mode. The Tridion CME redirects the browser to the ADFS form login page where ADFS takes the username/password of the user. Upon successful login, the ADFS server issues a token that it attaches to a POST request back to the SDL Web CME:

The following screen defines the SDL Web CME endpoint that ADFS posts the encrypted token to upon a successful login:

Finally, this is out Relying Party application we just created:

Next, we need to define which attributes from Active Directory we want the SAML token to contain. These are called claims and they are encrypted in the SAML token. It is the responsibility of the Relying Party application (SDL Web CME in this case) to decrypt these claims and use the user name in the claim to impersonate the Tridion user using the Single Sign-On module.

In ADFS, we create a Claim Provider Trust, and in it one or more rules defining the attributes and their format to send as claims:

If we want to send back Active Directory attributes, without transforming them, we can create the following rule:

If we want to send claims and transform them, we can create some simple transforming rules. For example, the rule below sends the "Windows account name" (i.e. the fully qualified domain name \ username) as a "Name" claim. This is important for when we deserialize the claims, because based on their 'Outgoing claim type' they are used to create an Identity object (at least in .NET) containing the user attributes such as name, first name, last name, email, roles, etc...

Eventually, our ADFS forms-login page looks like the one below:

Note: the login page in ADFS cannot be accessed directly. It only displays if the request POSTs to it using one of the defined Relying Party identifiers.


Popular posts from this blog

Running sp_updatestats on AWS RDS database

Part of the maintenance tasks that I perform on a MSSQL Content Manager database is to run stored procedure sp_updatestats . exec sp_updatestats However, that is not supported on an AWS RDS instance. The error message below indicates that only the sa  account can perform this: Msg 15247 , Level 16 , State 1 , Procedure sp_updatestats, Line 15 [Batch Start Line 0 ] User does not have permission to perform this action. Instead there are several posts that suggest using UPDATE STATISTICS instead: I stumbled upon the following post from 2008 (!!!), , which describes a way to wrap the call to sp_updatestats and execute it under a different user: create procedure dbo.sp_updstats with execute as 'dbo' as

Scaling Policies

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the

Toolkit - Dynamic Content Queries

This post if part of a series about the  File System Toolkit  - a custom content delivery API for SDL Tridion. This post presents the Dynamic Content Query capability. The requirements for the Toolkit API are that it should be able to provide CustomMeta queries, pagination, and sorting -- all on the file system, without the use third party tools (database, search engines, indexers, etc). Therefore I had to implement a simple database engine and indexer -- which is described in more detail in post Writing My Own Database Engine . The querying logic does not make use of cache. This means the query logic is executed every time. When models are requested, the models are however retrieved using the ModelFactory and those are cached. Query Class This is the main class for dynamic content queries. It is the entry point into the execution logic of a query. The class takes as parameter a Criterion (presented below) which triggers the execution of query in all sub-criteria of a Criterio