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

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: https://dba.stackexchange.com/questions/145982/sp-updatestats-vs-update-statistics I stumbled upon the following post from 2008 (!!!), https://social.msdn.microsoft.com/Forums/sqlserver/en-US/186e3db0-fe37-4c31-b017-8e7c24d19697/spupdatestats-fails-to-run-with-permission-error-under-dbopriveleged-user , 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

Content Delivery Monitoring in AWS with CloudWatch

This post describes a way of monitoring a Tridion 9 combined Deployer by sending the health checks into a custom metric in CloudWatch in AWS. The same approach can also be used for other Content Delivery services. Once the metric is available in CloudWatch, we can create alarms in case the service errors out or becomes unresponsive. The overall architecture is as follows: Content Delivery service sends heartbeat (or exposes HTTP endpoint) for monitoring Monitoring Agent checks heartbeat (or HTTP health check) regularly and stores health state AWS lambda function: runs regularly reads the health state from Monitoring Agent pushes custom metrics into CloudWatch I am running the Deployer ( installation docs ) and Monitoring Agent ( installation docs ) on a t2.medium EC2 instance running CentOS on which I also installed the Systems Manager Agent (SSM Agent) ( installation docs ). In my case I have a combined Deployer that I want to monitor. This consists of an Endpoint and a

SDL Web 8 - Content Delivery Microservices

Among the new features in SDL Web 8 there are the Content Delivery Microservices, namely: Audience Manager Content Deployer Contextual Image Delivery Discovery Service Dynamic Content Dynamic Linking Profiling and Personalization Metadata Query Taxonomy User Generated Content These microservices make up the Content Interaction Services and they expose the existing Content Delivery in-process APIs as RESTful services. They provide the server-side component in a Services-Oriented Architecture and act as data layer between the the web client and the Content Delivery Storage Layer. According to the SDL marketing, these microservices: Simplify upgrades, thus offering shorter time to value Modernize architecture, offering better separation between the web application and Tridion APIs Offer more flexibility with less downtime and improved scalability Improve quality, being self-running, contained and having less dependencies In technical words, these microservices