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. 

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

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

Children