Which .NET version for GroupShare custom authentication provider

Can anyone clarify which version of the .NET Framework we should use when building a custom authentication provider for GroupShare 2017?

Romulus' blog post states v4.5.2 but that was written for GroupShare 2015.

He also mentions that the project should reference two SDL assemblies - I first of all tried building a project against v4.5.2 with those referenced assemblies but it wouldn't build until I changed the project to v4.7.2. I decompiled those assemblies and found that they were built for v4.7.2.

So I built the custom authentication provider against .NET Framework v4.7.2 and got it signed. But when I drop it into place on the server, along with the accompanying *.plugin.xml file, I can't log-in.

Furthermore, my custom authentication provider should record attempts in a log file and the log file isn't even being created, so it looks like there isn't a bug inside the custom provider but outside - i.e., in the building of it.

I've also checked Windows' Event Viewer but there are no errors recorded around the time of my log-in attempts.

And I've decompiled a few other Sdl.*.dll files in the same folder and found that some are v4.5.2 and others are v4.7.2 - my guess is that maybe different GroupShare services use different versions of .NET?

So which is it for the custom authentication provider, v4.5.2 or v4.7.2? If the former then how can I reference those two SDL assemblies which were built against v4.7.2, and if the latter then...  any ideas why mine isn't being implemented on GroupShare?

Parents
  • 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. 

Reply
  • 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. 

Children
  • 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?

  • 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".