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.


Comments

Popular posts from this blog

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

A DD4T.net Implementation - Custom Binary Publisher

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

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