Shared Secrets and the 1E PowerShell Toolkit

This article describes the use of shared secrets on the 1E platform and their management with the 1E PowerShell Toolkit.

Before release 26.5 of the 1E platform, shared secrets could only be added but not deleted. This meant that reverting a configuration change required access to privileged configuration management services outside the platform instance.

Do not use shared secrets on platform releases earlier than 26.5. Release 26.5 introduced the ability to remove shared secrets, allowing testing to revert to a previous configuration without requiring access to configuration management services.

Before attempting to add a shared secret, ensure you have configured the platform for non-interactive authentication, and that you can authenticate non-interactively if required. Adding a shared secret immediately causes the platform to perform interactive authentication using that secret. If the associated interactive authentication application on the identity provider platform is not reconfigured appropriately, interactive authentication will be disabled until it is, or the shared secret is removed. However, to remove it, you need an authenticated session.

About shared secrets

During interactive authentication to Microsoft Entra, the redirect URL configured against the interactive authentication app is configured for an SPA platform by default. This means that Entra expects the interactive grant flow to be invoked from a web browser, and that the caller will supply an Origin header.

When the token redemption phase of authentication occurs, this is performed by the platform server and not the web browser. Entra will accept this redemption request as long as the server also includes an Origin header. In this configuration, no additional shared secrets are required.

Shared secrets and Entra Conditional Access Policies

In some circumstances, customers define Conditional Access Policies for Entra, which mandate multi-factor authentication (MFA) but only outside a defined corporate perimeter. Users logging on from within this perimeter do not require to use MFA.

When this is done, Entra will refuse the token redemption request if the original caller was inside the perimeter because it sees the platform’s IP address as lying outside the perimeter.

To remedy this, you can do one of the following:

  • Whitelist the platform IP addresses associated with the Azure instance on which it runs.

  • Configure the interactive authentication app to associate redirect addresses with the web platform rather than the SPA platform.

Some customers prefer not to implement the first option. In these cases, the second option can be used as an alternative.

If this is done, Entra expects that an additional shared secret is supplied during token redemption and will then accept the redemption request even though the platform IP address lies outside the perimeter.

You then must configure one or more shared secrets. You do this firstly inside the Entra app that will give you a shared secret that you can copy to the clipboard. You then use the PowerShell shared secrets cmdlets to manage these shared secrets. Refer to PowerShell Toolkit cmdlets to manage shared secrets.

The platform will always attempt to use the shared secret that is both valid and has the oldest expiry date. You should always ensure you configure additional secrets so that when they expire, both the platform and Entra will use the appropriate secret.

PowerShell Toolkit cmdlets to manage shared secrets

The Toolkit now provides cmdlets to make shared secret management easier. They are just wrappers over the underlying platform configuration APIs, which are how these secrets are actually managed. For more information, refer to Platform server management cmdlets.