Strong Names provide .NET Framework assemblies with unique identities. When the .NET Framework loads a strong-named assembly for a referring assembly, it verifies the strong name signature. If the strong name signature of the assembly cannot be verified, the .NET Framework will not load the assembly.

!Do not rely on strong names for security. They provide a unique identity only!

Alternatively in our case, BizTalk assemblies are loaded into the Global Assembly Cache (GAC). In this case, instead of the .NET Framework verifying the assembly identity each time it requires loading, the assembly identity is verified once when installed into the GAC.

Why do we need to strong-name our BizTalk assemblies:

1. Strong-naming is required if we want to store our assembly in the GAC.
2. The assembly can be loaded side by side with other versions of the assembly.
3. The assembly can be referenced and used by other strong-named assemblies.
4. Strong-naming can prevent assembly conflicts.
5. Strong-naming prevents spoofing of your code (malicious user can modify your code but cannot re-sign it as you)

   ! Only as long as you keep the private key secure !

Problem Space

One of the big NO NO's when it comes to strong-naming assemblies is, do not add, remove, or change the strong naming key that is used to sign the assembly. Reasoning behind is that by modifying the assembly’s strong-name key you have effectively changed the assembly’s identity. This means any application that uses the assembly will be requiring the assembly with the previous signed public key, thereby .NET Framework will fail verification and or the assembly with that identity wont be found in the GAC.

However, what if you find yourself in the position where:

1. You have lost the Signing Key that was used to strong-name your assembly.
2. You have previously password protected your Signing Key but have now forgotten/lost the password.
3. Your Signing Key has been compromised and you believe a malicious user might wish to modify and re-sign.

In this situation, we need to find a way to regenerate a signing key, and update our BizTalk Applications referencing points so that it knows to look for our assembly with the new identity.

Solution

Every strong-named assembly has a public key that it is identified by, in this case referenced by your BizTalk Application. Each BizTalk Application will reference its dependant assemblies(schemas, maps, orchestrations etc.) through its Bindings of which will also contain the public key for the relevant assemblies. It is this public key that will need to change to the new public key in order to retain the correct assembly identity reference. As part of this verification process, you will also need to make sure the you are referencing the correct version of the assembly.

For Example: Orchestration

 <ModuleRef Name="Application.Orchestrations" Version="1.0.0.0" Culture="neutral" PublicKeyToken="PublicTokenToBeReplaced" FullName="Application.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=PublicTokenToBeReplaced">

For Example: Pipeline

<ReceivePipeline Name="Application.Pipelines.FlatFileReceivePipeline" FullyQualifiedName="Application.Pipelines.FlatFileReceivePipeline, Application.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=PublicTokenToBeReplaced" Type="1" TrackingOption="ServiceStartEnd MessageSendReceive PipelineEvents" Description="" />

If you are like me, all my BizTalk Applications are deployed using the BizTalk Deployment Framework allowing me to conduct repeatable deployments without manual configuration and setup between environments. In this case you will need to update your PortBindingsMaster.xml file to replace the public key tokens as shown above.

If deployed manually from scratch, by setting up your ports, orchestrations etc. you will be setting up the new public key link by default. If deploying over the solution, then you will see in your Applications resources two of the same assembly but different PublicKeyToken. You will need to restart host instances (reloads assemblies) and then either update the references to point to the new version of the assembly or you may need to extract the bindings for the application, replace the Public Token, and then import the bindings. Be aware that any secrets held in your bindings will not be extracted and therefore you may need to re-enter these after you import. Once the references to the new assembly are complete, you can remove the old reference.

Retrieving New and Old Public Key from Strong Name Key

BizTalk Server Admin Console

The simplest method of retrieving the current (old) public key is to have a look in the BizTalk Server Admin Console.

1. Navigate to your Application in BizTalk.
2. Navigate to Resources.
3. Find your assembly in the list of resources you are updating.
4. The Name of the assembly contains the PublicKeyToken.

This method is useful if you have lost the current Strong Name Key, or have forgotten the password.

Strong Name Tool Sn.exe

This method relies on the fact that you still have the current (old) strong name key (if password protected, the password) and have already created the new key.

1. Load Visual Studio Developer Command Line.

2. CD to the path that holds your Strong Name Keys

3. Enter the following command

   sn -p NameOfKey.snk(can also be .pfx) token.snk

   This command extracts the public key from the key pair in the provided strong name and stores it in the new file token.snk

4. (Password Protected) If you provided a .pfx file, you will be prompted with a password, enter the password that protects the key.

5. Enter the following command

   sn -t token.snk

   This command displays the public key stored in the new file token.snk

These steps can be followed for both the old key to be replaced and the new key.

Sources

1. Using Strong Name Signatures | https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/july/clr-inside-out-using-strong-name-signatures

2. Strong-named assemblies | https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

3. Global Assembly Cache | https://learn.microsoft.com/en-us/dotnet/framework/app-domains/gac

4. Creating a Strong-Named BizTalk Assembly | https://learn.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/lesson-2-creating-a-strong-named-biztalk-assembly-for-the-swiftschemas-project

5. Sn.exe (Strong Name Tool) | https://learn.microsoft.com/en-us/dotnet/framework/tools/sn-exe-strong-name-tool

6. Deployment Framework for BizTalk Server V5.5 | http://www.tfabraham.com/BTDFDocs/V5_5/

7. Strong Naming | https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

One of the fundamental parts to BizTalk for both configuration and integration applications is Enterprise Single Sign On, or as we will continue to reference as SSO from now on.

SSO outside the bounds of BizTalk is an available service that is used to store and transmit encrypted user credentials. However, due to the nature of the service it is fairly generic, this has meant that many middleware applications and custom adapters have been designed to leverage SSO to securely store and transmit secure settings.

The SSO System holds any secure values in logical entities called Affiliate Applications. Affiliate Applications represent a system or sub-system, back-end system, or line of business application.

Looking back at BizTalk, each deployed application (Line of business application) is setup in SSO as an Affiliate Application. BizTalk uses the Affiliate Application to store internal configurations such as secure adapter data and configuration.

This post is written in mind for a BizTalk project that makes use of the BizTalk Deployment Framework (BTDF). I would highly recommend making use of BTDF as it will assist you in conducting repeatable deployments without manual configuration and setup between environments.

BTDF when added to your BizTalk project will include a SettingsFileGenerator.xml. This file will enable you to configure environment settings that are used to tokenise your PortBindings configuration and more. Another key aspect to this file, is that you can include settings that are utilised by your integrations at run-time such as database connection strings. When you deploy your application(s) to BizTalk, the selected environment settings are deployed to the Affiliate Application in SSO. These settings are encrypted at rest, and are available from anywhere within the BizTalk group.

Problem Space

SSO is brilliant for securely storing my settings, but how would I securely get those settings there?

One of the big problems with the BizTalk Deployment Framework SettingsFileGenerator.xml is that it stores your integration environment setting values in plain text, to add to the issue, this file is usually checked into source control.

Now you might think that you would be able to tokenise the settings values and then replace them at a CI/CD level. Agreed this is one step further into secure storage and removal of these values in source control. However, this file will still then contain your secure setting values in plain text as part of a CI/CD artefact, and this file will exist on the BizTalk App box that the deployment has occurred on. So you are still no further secured.

Solution | Secure Deployment

When your BizTalk Application msi is extracted as part of a deployment (extracted onto the App Box Programs x86), the msi will have included some framework deployment tools. One of these tools is the SSOSettingsEditor.exe. This editor will allow you to specify the Affiliate Application name, of which it will then display all the currently deployed settings and values in SSO for that application. This editor will also allow you to edit such values.

Handily, this editor is backed by a DLL that has also been made available in the same folder SSOSettingsFileReader.dll. This means we can use this DLL as part of our CI/CD pipeline as a post deployment step to update values in SSO. So how do we do this?

Firstly, we will require our handy SettingsFileGenerator.xml, we still want our setting being loaded into SSO for us to update later, but don’t require the value to be the real one. It can be a dummy value, and so we don’t mind it being in plain text.

Secondly, we can use PowerShell and the SSOSettingsFileReader.dll as a Post Deployment Step. The DLL contains a set of static classes and methods of which we can make effective use of. For this use case, we will require [SSOSettingsFileManager.SSOSettingsManager]::WriteSetting. The WriteSetting method takes three parameters:

1. The Affiliate Application Name | this will be the name of your project as seen in your .btdfproj
2. The Setting Name | this is the name of the setting that you wish to replace it’s value.
3. The New Setting Value | this is the value you wish to replace the default with.

After you have run this command, you can verify the changes have been made with the SSOSettingsEditor.exe as mentioned above.

Solution | Reading from SSO in your Integration

Let’s assume that you have an integration that will require a setting value from SSO such as a database connection string. To access this setting we can make use of the same DLL as mentioned above. There is another static class and method that will read a value from SSO:

• [SSOSettingsFileManager.SSOSettingsFileReader]::ReadString

This method takes two parameters:

1. The Affiliate Application Name | this will be the name of your project as seen in your .btdfproj
2. The Setting Name | this is the name of the setting that you wish to retrieve.

To make such as call, you will need to:

1. Add the DLL as a reference to you BizTalk Project.
2. Include the DLL as a component, this is done in your .btdfproj
3. Add the call to your integration as either:
   1. A variable in your orchestration.
   2. A Scripting Functoid calling the external assembly in a Map.

Conclusion

Provided both solutions, you can now specify your own secure integration settings values where these values are only stored as secure variables in your CI/CD and passed into SSO, and then read these values into your integrations straight from SSO. These secret values no longer need to live in plain text.