Yet Another Tridion Blog

In order to use SDL Web 8.5 and ADFS, we first have to enable SSO (Single Sign-On) on the SDL Web side. The setup I have is: SDL Web 8.5 installed in AWS (but it is the on-premise version of SDL Web) Active Directory outside of AWS ADFS outside of AWS, but somewhere close to AD HTTPS access to SDL Web CME website For this setup to work, we need to enable/configure a few things: enable HTTPS access to the CME enable/configure SSO on the CME ADFS SAML Authenticator Enable HTTPS In PowerShell, run the script  SetupHTTPS.ps1 from folder [SDLWebHome]\bin\Configuration Scripts . A very detailed explanation of this process is available at https://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v5/GUID-D694CEFB-AE01-415E-B919-5867C08E0A18. A prerequisite of enabling HTTPS is obtaining and installing a SSL Certificate. This is beyond the scope of this blog post, but the PowerShell script above expects the 40 character certificate thumbprint as a parameter. After run...

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...

This post describes how to convert the 'sdl-healthcheck' application to a Windows Service. SDL-healthcheck is a Java application that creates a webservice around the SDL Web microservices in order to provide monitoring (heart beat) checks on them. Mark van der Wal wrote the application and provided startup and stop Shell scripts. My requirement was to have the same application installable and executable as Windows Service. Therefore, I had to wrap the Java application inside a service container and provide start, stop hooks for the service. I know that SDL Web Content Delivery microservices are also Java applications using Spring Boot, so my approach was to use the same mechanism to make the Java application run as Windows Service. The service container used is 'procrun.exe' daemon from Apache Commons . Depending on the arguments passed to it, it can perform different Windows Service functionality such as install, remove service, start/stop service. I ended ...

In order to squeeze the most performance out of the publishing in a Tridion, SDL Web system, there is a high amount of parameters and configurations that must all be optimized. This post presents a few of these parameters, especially in the context of AWS infrastructure. CME The Tridion GUI, the Content Manager Explorer server is a normal Tridion installation, but with Publisher and Transport services disabled. This server is only used for running the website -- the CME. Publishers Publisher servers are Tridion installations without the CME. Namely these servers have the Publisher and Transport services enabled and any other Tridion services, if installed, are disabled. The purpose of a Publisher is simply to lookup publishable items in the Publishing Queue and proceed to render them, hand them over to the Transport service and have the transport package pushed to the Content Delivery. Publishers should use approximately twice the number of CPU cores as number of renderi...

When a Deployer Receiver receives a transport package, it notifies the Deployer Workers there is 'work' for them to do. This notification can take the form of JMS messages sent using some kinds of queuing mechanism. This post describes the Amazon Simple Queuing Service (SQS) to send these notifications. The Deployer workers receive these messages from SQS and they start deploying/undeploying the package. In order to setup this notification system, we must first create the SQS queues and configure them across the Deployer Receiver and all Deployer Workers. Start by creating Standard Queues using all default properties. We need 3 queues (commit, content, and prepare): Once the SQS queues are in place, we can configure the Deployers to use them in the file  deployer-config.xml . Amazon gives us the queues URLs. We need to specify the URL base separately, and then simply name the queues individually, as per below: <Queues> <Queue Default= "true...

When a Deployer Receiver receives a transport package, it notifies the Deployer Workers there is 'work' for them to do. This notification can take the form of files on a shared File System. The Deployer workers monitor the file system and upon noticing a change, they start deploying/undeploying the package. In order to setup this File System notification system, we must first create a shared File System (shared across the Deployer Receiver and all Deployer Workers). In order to do that, have a look at an earlier post Using Elastic File System for Out-Scaled Deployers . Once the EFS is in place, for example under folder /efs01 , we can configure the Deployers to use this share file system in the file deployer-config.xml , as per below: <Queues> <Queue Default= "true" Verbs= "Content" Adapter= "FileSystem" Id= "ContentQueue" > <Property Name= "Destination" Value= "/efs01/deployer-queu...

In a scaled-out scenario for Content Delivery Deployers, it is possible to setup an AWS ElastiCache Redis DB as the Binary Storage medium for incoming transport packages. The Deployer Receiver writes these transport package zip files into the Binary Storage Redis instance. Then it is up to the Deployer Workers to read these zip files as they deployer/underploy the content. Below, we present the configurations for an AWS ElastiCache Redis acting as storage medium for transport packages. Start by simply creating an ElastiCache Redis instance in AWS console. This whole step might take you 5 minutes :) AWS will give you the hostname where the Redis DB is available and the port, usually 6379. In your deployer-conf.xml , setup this Redis instance using the BinaryStorage node format as below:     <BinaryStorage Id="RedisStorage" Adapter="RedisBlobStorage">         <Property Name="Host" Value="10.10.2.232"/>       ...