Node.js + Express + TypeScript

The Node.js + Express + Javascript is a great platform and this short tutorial shows how to add TypeScript to the picture.

Start with installing TypeScript compiler globally

npm install typescript -g

so that whenever you invoke tsc from the command line, the compiler follows your tsconfig.json and does its job. Then add the tsconfig.json

{
    "compilerOptions": {
        "lib": [
            "es2021", "DOM"
        ],
        "module": "commonjs",
        "target": "es2021",
        "strict": true,
        "esModuleInterop": true,
        "sourceMap": true                
    }
}

Note that we specifically ask the module subsystem to translate TypeScript's export/imports into node.js commonjs modules. We also turn on the esModuleInterop flag for better node.js compatibility.

Now install some typings for node and express (other typings should possibly also be installed, depending on what packages you are going to use.

npm i --save-dev @types/node
npm i --save-dev @types/express

Create the app.ts file, which will be the starting point of the app and add .vscode/launch.json with

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "pwa-node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}\\app.ts",
            "outFiles": [
                "${workspaceFolder}/**/*.js"
            ]
        }
    ]
}

Note how the entry point (program) is set up here. Because the Typescript compiler will generate source maps, you would be able to run&debug the Typescript code.

Writing Typescript is easy now. Create an example express app

import * as http from 'http';
import express from 'express';

var app = express();

app.get('/', (req, res) => {
    res.write('hello world');
    res.end();
});

var server = http.createServer(app)

server.listen(3000);

console.log( 'started' );

Note how express is imported and how a library module (http) is imported - in both cases, there's the full intellisense support in VS Code as well as the support from the Typescript compiler.

To compile the code just invoke

tsc

once. To run the compiler in the watch mode:

tsc --watch

To show how TS modules work, create a simple module, m.ts with

class Example {
    DoWork( s: string ) : string {
        return s + ' from Example';
    }
}

export default Example;

and import it in the app.ts

import * as http from 'http';
import express from 'express';
import Example from './m';

var app = express();

app.get('/', (req, res) => {

    let e = new Example();

    res.write(e.DoWork('hello world'));
    res.end();
});

var server = http.createServer(app)

server.listen(3000);

console.log( 'started' );

Note how m.ts is compiled to m.js and also note how m.js is imported in the app.js (compiled from app.ts).

Simplest SAML1.1 (WS-Federation) Federated Authentication in .NET 6

Years ago I've blogged on how to do the WS-Fed using code only in .NET. The approach had multiple advantages over the static WSFederationAuthenticationModule (the WSFam) configured in web.config. The most important feature here is that you have the most control over what happens: how the redirect to the Identity Provider is created and how the SAML token response is consumed.

This is extremely useful in complex scenarios, e.g. in multitenant apps where tenants are configured individually or multiple identity providers are allowed or even when the federated authentication is optional at all.

.NET 6 (.NET Core) has its own way of handling WS-Federation, namely, it registers its own middleware (AddWsFederation) that can be controlled with few configuration options. However, I still feel I miss some features, like triggering the flow conditionally in a multitenant app. What I need is not yet another middleware but rather, a slightly more low-level approach following the basic principle: not use module/middleware but rather have a custom code in the logon controller/action:

if ( !IsWsFedResponse() )
{
   RedirectToIdP();
}
else
{
  var token = GetTokenFromResponse();
  var principal = ValidateToken();
  
  AuthenticateUsingPrincipal(principal);
}

Please refer to the blog entry I've linked at the top to see the approach presented there follows this.

Can we have a similar flow in .NET Core? Ignore the middleware but rather have a total control over the WS-Fed?

The answer is: sure. Since the docs are sparse and there are not-that-much examples, a decompiler is handy to just see how things are done internally so we don't rewrite anything that's already there.

So, just setup your cookie authentication and point your unauthenticated users to /Account/Logon. And then:

public class AccountController : Controller
{
	private KeyValuePair Convert(KeyValuePair pair)
	{
		return new KeyValuePair(pair.Key, pair.Value);
	}

	public async Task Logon()
	{
		WsFederationMessage wsFederationMessage = null;

		if (HttpMethods.IsPost(base.Request.Method))
		{
			var parameters = (await this.Request.ReadFormAsync()).Select(Convert);
			wsFederationMessage = new WsFederationMessage(parameters);
		}

		if (wsFederationMessage == null || !wsFederationMessage.IsSignInMessage)
		{
			var signInMessage           = new WsFederationMessage();
            
			signInMessage.IssuerAddress = "https://issuer.address/tenant/fs/ls";
			signInMessage.Wtrealm       = "https://realm.address/tenant/account/logon";

			var redirectUri = signInMessage.CreateSignInUrl();

			return Redirect(redirectUri);
		}
		else
		{
			string token = wsFederationMessage.GetToken();

			SecurityToken validatedToken;

			var tokenHandler = 
				new SamlSecurityTokenHandler()
				{
					MaximumTokenSizeInBytes = Int32.MaxValue                        
				};
			var tokenValidationParameters = new TokenValidationParameters()
			{
				AudienceValidator = (audiences, token, parameters) =>
				{
					return true;
				},
				IssuerValidator = (issuer, token, parameters) =>
				{
					return issuer;
				},
				IssuerSigningKeyValidator = (key, token, parameters) =>
				{
					if ( key is X509SecurityKey )
					{
						X509SecurityKey x509Key = (X509SecurityKey)key;

						// validate cert thumb
						// return x509Key.Certificate.Thumbprint == "alamakota";
						return true;
					}
					else
					{
						return false;
					}
				},   
				IssuerSigningKeyResolver = (token, securityToken, kid, parameters) =>
				{
					var samlToken   = (SamlSecurityToken)securityToken;
					var signature   = samlToken.Assertion.Signature;
                    
					// rewrite this to handle edge cases!
					var certificate = signature.KeyInfo.X509Data.FirstOrDefault().Certificates.FirstOrDefault();

					var x509Certificate2 = new X509Certificate2(System.Convert.FromBase64String(certificate));

					return new List()
					{
						new X509SecurityKey(x509Certificate2)
					};
				}
			};

			// if this succeeds - we have the principal
			var validatedPrincipal = tokenHandler.ValidateToken(token, tokenValidationParameters, out validatedToken);

			// we strip all claims except the user name to have a complete control over how the cookie is issued
			List claims = new List
				{
					new Claim(ClaimTypes.Name, validatedPrincipal.Identity.Name)
				};

			// create identity
			var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
			ClaimsPrincipal principal = new ClaimsPrincipal(identity);

			await this.HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);

			return Redirect("/");
		}
	}
}

Note how the IssuerSigningKeyValidator delegate replaces the IssuerNameRegistry from the .NET Framework example (linked blog entry). Also note, that other configuration options of the TokenValidationParameters can be changed freely here on a per-request basis.