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