How you could build a custom Web Application using Modern Authentication on Tridion Docs 15?

How you could build a custom Web Application using Modern Authentication on Tridion Docs 15?

This post describes how to develop and set up a custom Web Application using Modern Authentication and Tridion Docs Web Services. An applied edition of  How did we do Modern Authentication in Tridion Docs 15?  

The preferred way of creating an extension is to use the Organize Space Extensibility mechanism, you don't have to do anything for Modern Authentication as it is handled by Organize Space.

If you want to create your own Web Application that consumes Tridion Docs content, you have to cater for Modern Authentication and this custom Web Application is an example of how this can be achieved.

The left column in the table below shows the Modern Authentication options used in Organize Space and Collective Spaces. The right column highlights what you get when using the extension points in Organize Space, (The extensions inherent the Modern Authentication options from Organize Space.)  The example Web Application we will walk through uses all these options except for the token refresh and session cookies are stored in memory which is not ideal for using it behind a load balancer.

Feature support
Tridion Docs 15
Standard Product (/ISHCS)
Tridion Docs 15
Secure Extensions (/ISHEXT)
Modern Authentication Yes Yes
Sign In Yes Yes
Refresh access token before it expires Yes Yes
Sign Out Yes Yes
Token Management

Session cookies using Backend-for-Frontend paradigm supported

Supporting Load-Balancing over shared session storage

Session cookies using Backend-for-Frontend paradigm supported

Supporting Load-Balancing over shared session storage

"No tokens in the browser" policy

No, Access Token remains on the server

No, Access Token remains on the server

Sliding Expiration Yes Yes
React to changes in the browser security model Yes Yes

This example Web Application uses Modern Authentication and communicates to the Tridion Docs Web Services (WCF/SOAP). It is based on React and ASP.Net Core but can also be done in other technologies.

  • It uses React to create the user interface, which is what you see and interact with on the web page.
  • It uses ASP.Net Core to handle the authentication, which is the process of verifying who you are and what you can access.
  • It uses ASP.Net Core to communicate with Tridion Docs Web Services that stores and manages documents.
  • The web application needs to know who you are before it can show you the documents.
  • To do this, it asks another software program, called an identity provider, to verify your identity.
  • The identity provider is a trusted third-party that can confirm your username and password.
  • The web application does not know or store your username and password.

Overview

The process of authentication works like this:

  1. When you open the Web Application and press the login button, it sends a request to the ASP.Net Core part of the program. It will initiate the login process by returning a redirect URL to Access Management (ISHAM) which act as a federation gateway to the identity provider.
  2. If you enter the correct username and password, the identity provider sends you back to the Access Management (ISHAM) with a special code, your identity token and optional claims.
  3. Based on your identity prover and/or claims Access Manager grant you access to this Web Application.
  4. The ASP.Net Core part of the program receives the access token from ISHAM and stores it in a secure place. It also sends you a small piece of data, called a cookie, that has a unique number, called a session id, that links to the access token.
  5. The cookie is stored in your web browser and sent to the ASP.Net Core part of the program every time you make a request to the web application.
  6. The ASP.Net Core part of the program checks the cookie and the session id, and finds the access token that matches it. It then adds the access token to a security message, called a claim, that it sends to the Tridion Docs Web Services part of the program.
  7. The Tridion Docs Web Services part of the program checks the claim and the access token, and decides what documents you can see and edit.
  8. The advantage of using a session store and a cookie with a session id is that the access token is not exposed to the web browser or the user, which makes it more secure and less likely to be stolen or misused.

The advantage of loading the Web Application from the same server as where the requests are sent to is that there is no need to configure CORS, which is a set of rules that allow different web applications to talk to each other. This makes it easier to set up and maintain the web application. The Tridion Docs Web Services do not need to be accessible from the internet, as long as the Web Application can connect to it. This makes it more secure and less vulnerable to attacks.

Remarks on the Demo Web Application

  • The session store is memory based and not suited for running multiple web applications behind a load balancer, session should be stored centralized.
  • There is no support for refreshing the access token.
  • The example shows the basics of building a secure web application. There are packages available for better token management, for example Duende BFF Security Framework 

Building the demo web application

  1. Install the .NET 8 SDK
  2. Have Visual Studio Code or an other IDE.
  3. Make sure you have a running Tridion Docs environment
  4. Make sure you have registered an application in Access Management
    • Login into Access Management
    • Select 'Applications'
    • Click 'Register application'
    • This demo application is using demo-web-application as the client id and is configurable
    • For allowed redirects URLs, add https://localhost:5173/signin-oidc, make sure you have a SSL certificate for localhost because most identity providers don't allow http. Follow link for generating a HTTPS certificate
    • Make sure the users have access to this demo web application, preferably configured in the identity provider, it also requires 'Tridion Docs Content Manager API' Services with role 'user'
  5. The appsettings.json contains configuration settings, make sure the ApplicationServiceUri and UserServiceUri point to your Tridion Docs instance
  6. {
      "Tridion": {
        "Authentication": {
          "Authority": "https://demo.tridion-docs.com/ISHAM",
          "ClientId": "demo-web-application",
          "CookieExpireTimeSpan": "00:00:10"
        },
        "WebServices": {
          "ApplicationServiceUri": "https://demo.tridion-docs.com/ISHWS/OWCF/WCF/API25/Application.svc",
          "UserServiceUri": "https://demo.tridion-docs.com/ISHWS/OWCF/WCF/API25/User.svc"
        }
      }
    }

Generate Web Services client code

For this demo web application only two Web Services (WCF/SOAP) endpoints are used.
The WCF client code is generated using dotnet-svcutil with the following command:

dotnet-svcutil --outputDir "./Connected Services/InfoShareApplication" --outputFile IshApplication.cs --namespace "*,ApplicationServiceReference" --internal --noTypeReuse --acceptCertificate "https://demo.tridion-docs.com/ISHWS/OWCF/WCF/API25/Application.svc" --projectFile ReactApp.Server.csproj
dotnet-svcutil --outputDir "./Connected Services/InfoShareUser" --outputFile IshUser.cs --namespace "*,UserServiceReference" --internal --noTypeReuse --acceptCertificate "https://demo.tridion-docs.com/ISHWS/OWCF/WCF/API25/User.svc" --projectFile ReactApp.Server.csproj

Running the Demo Web Application

Run the application from your IDE or command line (in the ReactAppExample.Server folder run command 'dotnet run')

20231208.InfoShare-15.1.4808.0.ReactAppExample.zip