Tridion Web/Sites Cloud: SSO and Custom Pages

Question

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=8.6.0.365, 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).

Answer 1

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

UPDATE

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:

<system.web>
    <compilation>
        <assemblies>
            <add assembly="Tridion.Security, Version=8.6.0.365, Culture=neutral, PublicKeyToken=ddfc895746e5ee6b" />
        </assemblies>
    </compilation>
  </system.web>

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

Answer 2

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?