Yet Another Tridion Blog

Using the Workflow listener service with ADFS authentication is quite straight forward, if we use the Basic Authenticator. The service WFListener.asmx is not a WCF service, therefore we can't use federation security on it. Instead we need to use Basic authentication and handle the ADFS behind the scene. The Basic Authenticator module exposes a Basic authentication scheme, while communicating with the ADFS server in the background. Once a user is successfully authenticated, it creates a Thread and HttpContext security contexts, so that the following modules in the .NET request processing pipeline execute in the new security context. As such, our client can define a Basic auth security using HTTPS transport and it will be able to connect to the service. App.config The .NET Console application I use as test client uses generated service proxy classes. The configuration presented below defines the endpoint to connect to and a simple HTTPS Basic auth transport. <system.ser...

Using either of the templating services (i.e. AssemblyTemplateUploadWebService.asmx and CompoundTemplateWebService.asmx ) with ADFS authentication is quite straight forward, if we use the Basic Authenticator . This one exposes a Basic authentication scheme, while communicating with the ADFS server in the background. Once a user is successfully authenticated, it creates a Thread and HttpContext security contexts, so that the following modules in the .NET request processing pipeline execute in the new security context. As such, our client can define a Basic auth security using HTTPS transport and it will be able to connect to the service. This is the same mechanism the Content Porter application is using (i.e. Basic auth). App.config The .NET Console application I use as test client uses generated service proxy classes. The configuration presented below defines the endpoint to connect to and a simple HTTPS Basic auth transport. <system.serviceModel> <bindings...

Content Porter uses Basic auth to communicate with the ImportExport service. This means the federated security approach will not work. Luckily, we have the Basic Authenticator that exposes the ADFS authentication as a basicHttp endpoint. Using this endpoint, the authenticator creates a new security principal and sets it in the current Thread and HttpContext . As such, Content Porter works again out of the box: For the Basic Authenticator to intercept requests for the basicHttp endpoint, I defined a regular expression that is matched against the URL of the request: <add key="BasicAuthPath" value="(?i)/templating/.+\.asmx|/webservices/(core|importexport)service\d{4,6}\.svc/(streamdownload_basichttp|basichttp|script(?!/js))|/wflistener/wflistener\.asmx|/webdav|/monitoring/tridionmonitoringagent.asmx"/> The expression above matches all requests to: /templating/ folder, and files that end with .asmx extension. These are the services  Asse...

Using the ImportExport service with ADFS authentication is quite straight forward, if we use the Basic Authenticator. This one exposes a Basic authentication scheme, while communicating with the ADFS server in the background. Once a user is successfully authenticated, it creates a Thread and HttpContext security contexts, so that the following modules in the .NET request processing pipeline execute in the new security context. As such, our client can define a Basic auth security using HTTPS transport and it will be able to connect to the service. This is the same mechanism the Content Porter application is using (i.e. Basic auth). App.config The .NET Console application I use as test client uses generated service proxy classes. The configuration presented below defines the endpoint to connect to and a simple HTTPS Basic auth transport. <system.serviceModel> <bindings> <basicHttpBinding> <binding name= "basicHttp" > ...

In a previous blog post, I talked about a SecurityTokenHandlers collection of different security tokens. This is a class from the .NET security framework and it allows a unified entry to different types of tokens. In this post, I explain the need for a validating Saml2SecurityTokenHandler . The code for my overloaded property is something like this: private SecurityTokenHandlerCollection securityTokenHandlers; private SecurityTokenHandlerCollection SecurityTokenHandlers { get { if (securityTokenHandlers == null ) { securityTokenHandlers = new SecurityTokenHandlerCollection( FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers); for ( int i = 0 ; i < securityTokenHandlers.Count; i++) { if (securityTokenHandlers[i] is Saml2SecurityTokenHandler) { securityTokenHandlers[i] = new ValidatingSaml2SecurityToke...

As mentioned in a previous blog post, this class takes care of the interaction with the ADFS server. Its main functionality is to request and decrypt SAML tokens from an ADFS server. The class makes use of the .NET security token API, which in order to be used, it has to be configured. The easiest is to configure it through XML, in one of the application's .config files: <system.identityModel.services> <federationConfiguration> <serviceCertificate> <certificateReference storeLocation= "LocalMachine" storeName= "My" x509FindType= "FindByThumbprint" findValue= "30 4e 10 91 73 fb 34 6a 90 19 f5 e7 d4 fa 2d 11 21 10 3e 3d" /> </serviceCertificate> </federationConfiguration> </system.identityModel.services> The configuration above allows us to use the predefined System.IdentityModel.Tokens.Saml2SecurityTokenHandler . I used this class to handle the reading (i...

This post presents a Basic Authenticator wrapper around ADFS security. This authenticator allows a client and web-service to use Basic authorization security, while the actual security authentication happens on an ADFS server. The Basic Authenticator is a .NET HTTP module, which creates a security context based on a user principal that it receives from ADFS. All subsequent request processing happens in the context of this 'impersonated' context. The request processing sequence is as follows: Client connects to web-service using Basic authorization (over HTTPS, so the  Authorization  request header is not transmitted in the open) Basic Authenticator HTTP module intercepts the request If  Authorization  header is in the request Extract and decode username/password from  Authorization header If username/password is valid in ADFS Create user principal Set security context Let request processing continue Else Send 401 WWW-Authenticate response hea...

If in an earlier post CoreService with ADFS , I was talking about XML configuration of the .NET client application when connecting to a SDL Web 8.5 instance secured with ADFS, in this post I am showing another way of connecting to the CoreService, namely using a SAML token requested through code rather than configuration. The main steps in this approach are: client .NET Console application requests programmatically a SAML token from the ADFS server client creates connection using issued token The setup on the SDL Web server and the configurations of the CoreService web-service are identical to those presented in the earlier post, therefore I won't mention them again here. App.Config The client is a .NET Console application using an App.config which defines the following CoreService endpoint: <system.serviceModel> <bindings> <ws2007FederationHttpBinding> <binding name= "myCoreServiceBinding" maxReceivedMessageSize= ...

This post presents a way to connect to the SDL Web 8.5 CoreService form a .NET client using ADFS federated security. In this particular setup, the client application -- a .NET Console application -- makes a call to the ADFS Security Token Service (STS) to request a token based on username/password combination. This is a so called active authentication scenario. If the username/password combination is correct, the STS issues an encrypted SAML token and send it back to the client application. The client is only the bearer of the token and it cannot decrypt it. The client then establishes a connection with the ADFS secured web service and passes on the SAML token. The web service decrypts the token and extracts the user principal, and perhaps additional claims (i.e. attributes of that user such as email, first, last names, etc). The service impersonates the user principal and creates a channel with the client application. All operations performed by the client in this channel are done...

This post continues the setup of Single Sign-On for Web 8.5 with ADFS presented in an earlier blog post. This SAML Authenticator is a .NET HTTP Module that is configured to intercept all requests going into the SDL Web website (the CME) and do the following: if request is post-back from ADFS decrypt SAML token extract user name set cookie with user name set user name in request SSO header else if cookie exists extract user name from cookie set user name in request SSO header else redirect browser to ADFS form-login The cookie is encrypted, in order to prevent the user name from being spoofed. In more detail, the code is as follows: public void BeginRequest () { string user = GetUserData(); if (user == null ) { Request.Headers.Remove(Configuration.HeaderUser); } else { Request.Headers[Configuration.HeaderUser] = user; } } The method executes when a request is intercepted. The configuration HeaderUser ...

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