Hi Andrew, 

You did not specify the version of GroupShare 2017 that you are using. Groupshare 2017 SR1 (version 14.2.7902.0) still targets .Net 4.5.2.

If not sure what version of .Net to target have a look at Sdl.StudioServer.Services.IdentityModel.dll, deployed under C:\Program Files (x86)\SDL\SDL Server\Application. This is responsible for loading any custom authentication plugins that you have. Use any tool that can decompile .Net assemblies to find out the target framework. 

As for the plugin you need to reference the following: 

- Sdl.Core.PluginFramework
- Sdl.Core.PluginFramework.PackageSupport
- Sdl.StudioServer.Api.Core

Keep in mind that the user type is what governs how the authentication happens. For custom authentication to be used, the user logging (identified by the username) must have the user type set to "CustomUser". The user type is set individually for each user and can't be changed. As a result, to test your custom authentication plugin, you need to make sure that you're trying the login with a "CustomUser". 

Let us know if you have any more questions and we will work it out. 

Hi Zoltan,

Thanks for the informative answer.

We're using GroupShare SR1 CU9 (14.2.47996.9). I disassembled the DLL you mentioned and found that it's using v4.7.2, which is the version against which our library is already built.

Another point to note is that Romulus' blog post doesn't mention that we need to reference Sdl.Core.PluginFramework.PackageSupport - are you sure that this is needed because our project at least builds without that reference?

And yes, I know that I was testing against a genuine 'CustomUser' because we already had a custom authentication provider installed. Unfortunately we no longer have the source code for that so this latest version was based upon a disassembled version of that older DLL. Consequently all our accounts - excluding the built-in 'sa' account - are custom users.

So the only difference is that I now have a reference to Sdl.Core.PluginFramework.PackageSupport in the project, and that means I have to send it again to be signed before I can try it. Is there any way that the identity model can load unsigned assemblies for testing/debugging purposes like we can do with Studio?

The problem I'm facing: The current signed and in-place version should create a log file in its constructor, then log all calls to `UserExists` and `ValidateCredentials` to this file. But the file is never created and when I attempt to log-in I'm told that the username or password is wrong. The evidence suggests that our library isn't being implemented. Do you have any suggestions for debugging this?

Could you try the following:

- Remove the custom plugin entirelly (dll and the files from the plugins folder) and restart Application Service.
- Try to create a custom user - you should get an error saying that no custom authentication plugin was found. 
- Copy back the plugin and restart Application Service. 
- Try to create a custom user again. This time, because the custom user type is used the plugin will be loaded and the UserExists method will be called to ensure that no user exists with the username. If you succeed creating the custom user then the plugin is working. 

Not sure how it can be debugged though. In the worst case I could upload a small signed plugin that logs operations and allows in custom users regardless of the password - just to test if that works. 

I tried exactly as you suggested, but for the last step it says that no custom authentication plugin can be found.

I've uploaded a zip of the DLL and the accompanying XML file - would you mind taking a look and letting me know if there's anything obviously wrong?

www.dropbox.com/.../NEW Supertext Auth Provider.7z

Could you upload the Supertext.GroupShare.AuthProvider.plugin.resources file as well, please?

There's no such file.

Should there be?

Hi again, Andrew, 

It's not mandatory to have the plugin resources file. 

Good news is that I had a closer look at the uploaded files and found why the plugin is not loaded. 
Your plugin XML file states that it's encoding is UTF-16, whereas if you look at the file it is not. The plugin framework reads that manifest file, but loading the XML fails. 

So either save the plugin XML as a valid UTF-16 or remove the encoding from the XML declaration. 
Removing the encoding, like this worked for me: 

<?xml version="1.0"?>
<plugin id="SupertextAuthenticationProvider" name="SuperTtxt Authentication Provider" version="1.0.0.0">
<extension type="Supertext.GroupShare.AuthProvider.AuthProvider, Supertext.GroupShare.AuthProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
<extensionAttribute type="Sdl.StudioServer.Api.Core.CustomAuthenticationProviderExtentionAttribute, Sdl.StudioServer.Api.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
<constructorArgs />
<properties />
</extensionAttribute>
<auxiliaryExtensionAttributes />
</extension>
</plugin>

Also, note, that you have a typo in the plugin name. 

Let me know if this works for you!

Hi Zoltan,

Yes, I got it working. I'm slightly puzzled by this, though, as our older version worked, and that had the UTF-16 declaration in the XML, despite being saved as a UTF-8 file. The XML file for the newer version was simply a copy of the older file, specifying the namespace of our new plugin. So yeah...  I'm puzzled as to why the older version continued to work but not the new version - and in-between attempts to use the new version I was replacing it with the old version so that other users could log-in, and this worked each time.

Furthermore, I remember when we deployed the older version several years ago and we couldn't get that to work. I emailed Romulus and we eventually found that the XML had to contain that UTF-16 declaration, which is why Romulus' blog post features an update stating this at the bottom of the page. So this fix kinda reverses the previous fix.

Anyway, it works now, and I'll continue to omit the UTF declaration altogether. Many thanks for seeing this through to the end, Zoltan.

The current behavior is correct, as the declaration says the file is UTF-16 but it's not. If you want to keep the UTF-16 declaration in the XML just create a new plugin XML file in Notepad++ or something and make sure it's UTF-16. I'm not sure what's caused the change. Could be plugin framework changes. Could be .Net framework version change that handles XML validation more "strictly". 

The current behavior is correct, as the declaration says the file is UTF-16 but it's not. If you want to keep the UTF-16 declaration in the XML just create a new plugin XML file in Notepad++ or something and make sure it's UTF-16. I'm not sure what's caused the change. Could be plugin framework changes. Could be .Net framework version change that handles XML validation more "strictly".