We are using SDL Tridion Web/Sites Cloud (8.6) and have a SSO implementation, so users are authenticated via a third party application (Azure AD in our case). We want to host a few custom pages, but cannot find any information about configuring the application that runs these to leverage SSO (otherwise users of the custom pages will not be able to log in). Has anyone done this?

I tried hosting the pages in a sub application of the main SDL Web IIS application, but it is prompting me for a username and password, rather than using SSO, so I guess some further configuration of this sub application is needed.

UPDATE I added the SAML Authentication Module (and removed the Ldap one) in the web.config of my custom page application:

<add name="SAML20AuthenticationHttpModule" type="Tridion.Security.Web.SAML20AuthenticationHttpModule,  Tridion.Security, Version=, Culture=neutral, PublicKeyToken=ddfc895746e5ee6b" />
<remove name="LdapAuthenticationHttpModule" />

Now I don't get a login prompt, but do get stuck in a 3 request loop:

  1. GET Request for my custom page - response contains HTML with Javascript to redirect to SAML login page
  2. GET Request to SAML login page - response contains a form which is posted with Javascript to the root /WebUI of the CME
  3. POST Request to /WebUI - response sets SAML cookies and has javascript to redirect to original request (back to 1)

Looking at the requests in Fiddler, the SAML cookies are passed on in request 1, so I am not sure why it still thinks I need to be authenticated (and thus returns the HTML with redirect, rather than my custom page).

  • I did play around with sites 9 SAML2.0 with Azure AD, I did manage to set up SAML2.0 setup successfully, I then tried to set up custom power page under SDL Web Root, seems it actually only works SSO redirects if we host under WebUI, not under root. because I can see the SAML2.0 module included in WebUI\web.config only seems needs some customization in the custom power pages to check the SSO authentication by Ajax calls by checking headers or cookies if you enable LdapAuthenticationHttpModule in your custom power page what is the behavior if you log in with SSO then try to access your page?
    – Velmurugan
    Commented Dec 17, 2018 at 11:38

2 Answers 2


As it was not possible to have a separate application use the SAML Authentication module (see Rick's answer) I had to take a step back and re-think how my custom pages work.

Because the custom pages are using the core service, what I really wanted was to make sure that core service calls were done in the context of the authenticated user of the Tridion UI. I managed to create a workaround for this using the following.

  1. Put an aspx page inside /Tridion/Web/WebUI/Webroot which reads the authenticated username (using HttpContext.Current.User.Identity.Name), encrypts it (I used the System.Security.Cryptography.ProtectedData class in the System.Security.dll - which I also had to add to Webroot/bin), puts it in a root cookie and redirects to my custom application (which is a separate application but running under the root SDL Web IIS application)

  2. In my Custom application(s) allow anonymous access (this is default for a SAML configured site, but you also need to disable the LdapAuthenticationModule: <remove name="LdapAuthenticationHttpModule" /> in the custom application web.config

  3. Add code in the custom application to read and decrypt the cookie with the user name.

  4. Impersonate using this username when creating a core service client (using the Impersonate method). In our case the username had to be prefixed with our authentication provider and a colon to make sure it matched the user in the CMS


If, like us you have group membership determined through the Authentication provider (and not directly linked to users in the CMS), then you will need to pass the claims data and use the ImpersonateWithClaims method when creating a Core Service client. You will need to add an assembly reference in the WebUI web.config:

            <add assembly="Tridion.Security, Version=, Culture=neutral, PublicKeyToken=ddfc895746e5ee6b" />

...and do something like the following to serialize the claims before encrypting and setting them in the cookie

string claimsData = String.Join("|",((Tridion.Security.ClaimsPrincipal)HttpContext.Current.User).Claims.Select(c=>c.Value + "^" + c.Type));
  • 1
    Idea created to allow SAML authentication to work across web apps: community.sdl.com/ideas/sdl-tridion-dx-ideas/…
    – Will Price
    Commented Dec 18, 2018 at 8:03
  • This is not the best workaround as if there are many claims, the cookie could quickly become too big (for the 4KB limit)
    – Will Price
    Commented Dec 18, 2018 at 15:00
  • Not to mention the fact that you create a nice security hole this way. I bet it is quite simple now to impersonate whoever you want with any group membership you want (e.g. System Administrator). Commented Dec 18, 2018 at 17:24
  • Well.. it is encrypted and can only be decrypted on the same server so there's no risk on client. But it would probably better implemented by posting the claims data to the custom app and using a session there or something to persist the claims
    – Will Price
    Commented Dec 18, 2018 at 19:13

IIRC, the current implementation for SAML 2.0 authentication uses ASP.NET Session State, which requires:

  • Use of Sticky Session on your Load Balancer (to prevent the same ASP.NET Session ending up on multiple CMS servers)
  • Use of a single Web Application

So, creating your own separate Web Application may not work. Can you create a Virtual Directory instead of a separate Web Application?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.