Active Directory vs. Windows Security Providers

Radzen Studio Blazor Server
1

I'm trying to understand the difference between these two providers - I've read all of the community posts and documentation about it, but it doesn't all make sense.

I'm going to try to list the features of each for clarity, and throw in MS LightSwitch as well.

Active Directory Provider:

  • Authenticates against Windows Domain - Yes
  • Authenticates against local Windows account - No
  • Single Sign On - No
  • Groups used for security roles - Domain

Windows Provider:

  • Authenticates against Windows Domain - No (or Yes? Unclear)
  • Authenticates against local Windows account - Yes
  • Single Sign On - Yes
  • Groups used for security roles - Local (and Domain? Unclear)

MS LightSwitch Windows Authentication

  • Authenticates against Windows Domain - Yes
  • Authenticates against local Windows account - No
  • Single Sign On - Yes
  • Groups used for security roles - Domain

Based upon some posts here, it seems that Radzen's Windows authentication does authenticate against Windows Domains? This isn't clear, and if it does, then why does the Active Directory provider even exist?

Conversely, if the Windows provider can't authenticate against a Windows Domain, then why does it exist? I've never even heard of an app that only supports local Windows security and can't imagine what the reasons could be for creating one. I guess the back-end database would also have to use it's own authentication mechanism?

I understand they you guys have probably implemented two different API's for each, but isn't the one you're using for you Active Directory provider deprecated and redundant? I don't know much about this topic, what am I missing here?

Thanks,
Slosuenos

1 Like
2

Assume you have an Active Directory for this to make sense

The different is that Active Directory Provider will allow non windows domain joined machine /non windows machines to login to the application. As it has a login page.

The Windows Provider will allow domain joined windows machine to use domain groups and local groups. Also it’s got to be a Windows machine. Non domain joined computer will not be able to use domain groups, but can use local groups.

You can test what each does by adding a textarea to a page and add this to the value property ${security.user.roles}.
image

You will get something like this for Domain XXXX

Domain Users,XXXX\Domain Users,Everyone,Everyone,Performance Log Users,BUILTIN\Performance Log Users,Users,BUILTIN\Users,INTERACTIVE,NT AUTHORITY\INTERACTIVE,CONSOLE LOGON,CONSOLE LOGON,Authenticated Users,NT AUTHORITY\Authenticated Users,This Organization,NT AUTHORITY\This Organization,LOCAL,LOCAL,Company users,XXXX\Company users,,DataAdmin,XXXX\DataAdmin

1 Like
3

Radzen's Windows authentication is Microsoft's Windows authentication. Nothing Radzen related there. If Microsoft's Windows Authentication works against domains so will Radzen's - you are welcome to test it with your own setup. If you have further questions about Windows Authentication you should better direct them elsewhere as we are not experts in the area.

Back in 2017 there was no Windows authentication support for .NET Core 1.x (which barely worked to be honest). We had to use Novell's LDAP client to implement a custom security provider which authenticates against a specified LDAP server (Windows domains implement the LDAP protocol).

The added benefit of the Radzen Active Directory security provider is that it will work on non-windows machines because it has a login page - just as @alistair said.

1 Like
4

Okay, thanks guys. So, in a nutshell you'd want to use the Active Directory provider if your webserver were running on a Linux / OSX system that could authenticate against a Windows Domain Controller. Use the Windows provider if webserver runs on a Windows server. Perfect!

Slosuenos