Rework search flow to minimize LDAP search results

[joshuaboniface]

The previous implementation would search for all users that potentially matched the (mandatory) configured search filter, then loop through the results to find a user matching one of the attributes.

This method worked fine for small instances, but became unwieldy for larger LDAP instances, and could even result in a Size Limit Exceeded error for extremely large databases.

This commit introduces a better method by integrating the user search component into the initial LDAP search by way of the search filter. This will ideally result in only a single LDAP search result for a given user rather than potentially dozens or hundreds, reducing both the runtime complexity of the plugin as well as the load on the LDAP server.

This new method has two potential ways of generating the limited search filter:

First, the existing search filter option may now accept a "{username}" variable within it, which will be interpolated at runtime based on what the user entered. This method allows for very complex queries to be crafted at will, providing better administrator flexibility and options.

Second, if no "{username}" variable is found within the search filter, the filter will be modified at runtime to include all of the search attributes combined with the username to generate a search query which will return any matches between the username and those attributes. For example, given attributes "uid" and "mail", a (base) search filter of "(objectclass=mailUser)", and the entered username "joshua", the following "real" search query would be produced:

(&(objectclass=mailUser)(|(uid=joshua)(mail=joshua)))

These two methods are, functionally, mutually exclusive: if the search filter contains the "{username}" variable, the search attributes will be ignored and may be blank/empty; on the other side, with valid search attributes, it is no longer necessary to specify a search filter at all, since there will still be a filter on the attributes and username. Thus, the plugin now accepts blank input for both fields in the configuration, though leaving both blank would not work properly.

In both cases with this change, searches are case-insensitive due to the case-insensitivity of LDAP search queries,, so the option for case-insensitive username searches has been removed as obsolete.

The new configuration is also backwards-compatible: if no changes are made to the search filter, the second method above will be used and this should continue to function exactly as expected.

Some debug messages have also been updated to provide a clearer picture of what the plugin is doing at various steps and aid in troubleshooting.

An explanation of the two methods above is included in the plugin configuration page, along with some rearranging of the options, to assist users in configuring the two fields the way they want.

Closes #139 #34
Obsoletes PR #71

[crobibero]

Changes look fine, I would just rewrite this to use a stringbuilder and clean up some unneeded code/warnings

Index: LDAP-Auth/LDAPAuthenticationProviderPlugin.cs
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs b/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs
--- a/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs	(revision 2e3875c55e4f91b80b34b5fb6435d6be5dfa305d)
+++ b/LDAP-Auth/LDAPAuthenticationProviderPlugin.cs	(date 1677680875839)
@@ -3,6 +3,7 @@
 using System.Linq;
 using System.Net.Security;
 using System.Security.Cryptography.X509Certificates;
+using System.Text;
 using System.Threading.Tasks;
 using Jellyfin.Data.Entities;
 using Jellyfin.Data.Enums;
@@ -323,7 +324,7 @@
                     LdapPlugin.Instance.Configuration.LdapBaseDn,
                     LdapConnection.ScopeSub,
                     filter,
-                    new string[] { UsernameAttr },
+                    new[] { UsernameAttr },
                     false);
 
                 // ToList to ensure enumeration is complete before the connection is closed
@@ -358,22 +359,36 @@
 
             string realSearchFilter;
 
-            if (SearchFilter.Contains("{username}"))
+            if (SearchFilter.Contains("{username}", StringComparison.OrdinalIgnoreCase))
             {
-                realSearchFilter = SearchFilter.Replace("{username}", username);
+                realSearchFilter = SearchFilter.Replace("{username}", username, StringComparison.OrdinalIgnoreCase);
             }
             else
             {
-                realSearchFilter = "(&" + SearchFilter + "(|";
+                var searchFilterBuilder = new StringBuilder()
+                    .Append("(&")
+                    .Append(SearchFilter)
+                    .Append("(|");
+
                 foreach (var attr in LdapUsernameAttributes)
                 {
-                    realSearchFilter += "(" + attr + "=" + username + ")";
+                    searchFilterBuilder
+                        .Append('(')
+                        .Append(attr)
+                        .Append('=')
+                        .Append(username)
+                        .Append(')');
                 }
 
-                realSearchFilter += "))";
+                searchFilterBuilder.Append("))");
+                realSearchFilter = searchFilterBuilder.ToString();
             }
 
-            _logger.LogDebug("LDAP Search: {BaseDn} {realSearchFilter} @ {LdapServer}", LdapPlugin.Instance.Configuration.LdapBaseDn, realSearchFilter, LdapPlugin.Instance.Configuration.LdapServer);
+            _logger.LogDebug(
+                "LDAP Search: {BaseDn} {RealSearchFilter} @ {LdapServer}",
+                LdapPlugin.Instance.Configuration.LdapBaseDn,
+                realSearchFilter,
+                LdapPlugin.Instance.Configuration.LdapServer);
 
             ILdapSearchResults ldapUsers;
             try
@@ -382,7 +397,7 @@
                     LdapPlugin.Instance.Configuration.LdapBaseDn,
                     LdapConnection.ScopeSub,
                     realSearchFilter,
-                    new string[] { UsernameAttr },
+                    new[] { UsernameAttr },
                     false);
             }
             catch (LdapException e)

[9SMTM6]

this, in combination with other unfortunate factors (jellyfin apparently not updating this plugin, it originally was 16, and me having the admin user also only in ldap), managed to seriously mess up my Jellyfin installation that authorized against kanidms LDAP API.

The 'fallback' of just adding the search attributes lead to an error on kanidm side since it lead to invalid expressions.

I managed to fix it by editing the config xml to include (spn={username}@kanidm.<my domain>) in <LdapSearchFilter>.