So my organization uses a custom Authentication extension to allow us to use on premise ADFS as our authentication mechanism. I do have a question about the loading of custom extensions though. It seems to me that you load custom extensions before you load any of your built in extensions?
As our ADFS extension is built on top of your OpenIDConnect library, like the AzureAD one, We have to drop the Octopus.Server.Extensibility.Authentication.OpenIdConnect.dll and the Octopus.Node.Extensibility.Authentication.OpenIdConnect.dll into the CustomExtensions directory to be able to get our extension to load.
The issue arises that with each new Octopus release, we need to keep these files updated to match the version bundled with the other built in extensions otherwise if we have a version that is older than the current bundled version, all the built in extensions fail to load as obviously an older version has already been loaded.
So my final questions are, Is this expected behavior? Could you look at loading all the built in extensions before loading custom extensions? Should I just be dropping our ADFS extension into the Built in folder to mitigate this issue?
Thanks for reaching out. After receiving your inquiry, one of our engineers decided to do a bit of a clean up with the extensions code. We are currently in the process of combining Octopus.Server.Extensibility.Authentication.OpenIdConnect.dll and the Octopus.Node.Extensibility.Authentication.OpenIdConnect.dll library into a single NuGet package. This package will be built separate from Octopus Server so the version wont change very often. When this becomes available, you will be able to reference this Nuget package in your custom custom authentication extension. Once you have a new extension built with this package, you will simply need to copy the extension DLL to the CustomExtensions directory without the dependent *Extensibility.Authentication.OpenIdConnect.dll assemblies.
I hope that helps. I will reach out to let you know as soon as the new NuGet package is available.
Hi Tom,
Thanks for the reply. I look forward to the new nuget packages. That will simplify some things.
I still don’t think it will solve the underlying issue though. If you were to follow the below steps, you might see the actual issue I am reporting.
Stop the Octopus Instance
Copy the Octopus.Server.Extensibility.Authentication.AzureAD.dll file from the BuiltInExtensions folder to the %ProgramData%\Octopus\CustomExtensions folder
Start the Octopus instance.
You will notice that Octopus will fail to start due to not being able to find the Octopus.Server.Extensibility.Authentication.OpenIDConnect.dll file (and if you add that you will see that you also need Octopus.Node.Extensibility.Authentication.OpenIDConnect, Microsoft.IdentityModel.Logging and Microsoft.IdentityModel.Tokens). So while I appreciate that simplifying the 2 OCtopus dll’s down to a single dependency will clean up some stuff, I don’t think it will solve the underlying issue that you load Custom Extensions before loading Built in Extensions.
It is by design that we load the custom extensions. It allows Octopus to load custom builds of the auth extensions overriding the built in ones. If we load a custom version of an extension with the same name as a built in one, we skip loading the built in one.
The change that we have made to combine the OpenIdConnect dlls (which can be found here) was meant to address the original issue you mentioned where you would need to rebuild your custom auth extension every time you upgrade your Octopus Server.
Apologies for my previous message, you will in fact need to have the OpenIdConnect dll along side the custom extension dll. If you were to build a new version of your extension using this new package, you should be able to place the dll and its dependencies in the CustomExtensions directory.
Your extension will only need to be rebuilt if/when the versions of the dependencies are updated in Octopus Server, which aren’t likely to change very frequently.