New simplified LDAP auth driver

[droptablespace]

Hello,
First, I would like to thank you for the amazing project. We use Directus for various internal projects and it really speeds up development and mitigate a lot of headache.
With the release of v9.0.0 new LDAP auth was introduced, which is great addition, but its internal flow, as I see it, is not suitable for organizations with complicated/messy LDAP structure. Below I would try to explain it in detail and propose a pull request.
Why:

1. Current ldap find user flow – It uses userDn as parameter to find a user in ldap with “one” parameter in ldapjs search, which requires this userDN to be almost full pass down to specific OU(Organization Unit). This makes it impossible to find user with different OUs of the same level(which, frankly, is usually a case in mid/big organizations with messy LDAP structure) - then current LDAP driver takes CN of found user and merges it with userDN and preforms search for additional attributes, which further complicates things(and usually won’t work)).
2. LDAP role management – with several OU and OU in OU(again hello to messy ldap structure), it’s almost impossible to configure the groups roles search right
   Proposed solution
   Create new type of auth driver(ldap-simple for example) or extend existing one which has the following differences in comparison to the standard LDAP auth driver:
3. LDAP user search is preformed over global DN (for example DC=enterprise) by some unique identifier like email with ‘sub’ attribute in ldapjs to retrieve name, email and distinguishedName.
4. DistinguishedName is used as external identifier in Directus and is the base to preform bind operation to auth the user(instead of CN + UserDN)
5. If the user already exists in Directus and the field “external identifier” is empty, distinguishedName is written into this field to give ability to the existing user to auth via LDAP
6. For every new user authenticating via LDAP the role is given according to the env. variable in which name of the already existing role is specified( for example standard role User). If no variable is set then a new user is created with an empty role.
   I have drafted proposed changes as new separate auth driver and can make a pull request to show it. Ready to provide additional details, considerations.

[aidenfoxx]

Not sure I fully understand all your issues, but I believe point 1 and 2 are addressed here where the search scope can be defined: #9529

Point 3: user info is selected using a users full DN including CN, so we get attributes specific to the authenticating user. I don't see the problem here?

Point 4: the external_identifier is the full distinguished name including the CN?

Point 5: kinda defies the point of LDAP IMO. Currently an LDAP user cannot authenticate with a default Directus account, and vice versa. This is intentional to offload user management to AD.

Point 6: also feels unnecessary. Currently the LDAP flow will find all groups belonging to a user and match the group name to an existing role in Directus. So if a user belongs to "Directus-Admin" in AD they will get a "Directus-Admin" role in Directus (if it exists). Otherwise the user is created with no role.

It feels like most of your issues will be solved by the linked PR?

[droptablespace]

Hi,
1-2,4. Yes #9529 will solve the scope issue for one part: it will allow search for users with recursively in function "private async fetchUserDn", but its return "for resolve(cn=${userCn},${userDn}.toLowerCase());" will not allow to run next function "private async fetchUserInfo" properly.
For example imagine we have LDAP structure like this: " OU=Department1, OU=Department2, DC=Enterprise, ". Each OU=Department has its sub OU where users are located, for example OU=SubDepartment1, OU=Department1, DC=Enterprise". In this case if we want to search in every sub department of every OU for users we need to set userDN to something like "DC=Enterprise" . If we run "private async fetchUserDn " with such settings it will return something like "CN=User Name, DC=Enterprise". And the result of that return will be passed to "private async fetchUserInfo" which will return noting as "CN=User Name, DC=Enterprise", is not the full path. That's why I suggest to use DistinguishedName (now I realize this attribute maybe only relevant for Active Directory) which is qualified DN and can be used as identifier in subsequent requests to LDAP.
4. Yes as I mentioned above DistinguishedName attribute is full path for LDAP entity(I will verify if it stands for every ldap implementation or only for Active Directory variant)
5 -6 . I agree, that the current implementation is great for offloading roles management to LDAP. Maybe I should paraphrase my initial proposal - I still what to use Directus as main role management system and ldap as only authentication, not authorisation system. In my personal situation, all ldap authed users end up in some generic role and a Directus admin assigns appropriate role for each one individually. This really helps in situation when internal structure of LDAP is not stable and is being constantly changed(users move from one department or to another or group), so in the end nobody in the org uses ldap as authorization, but simple authentication tool.

[aidenfoxx]

Your example will also be fixed by #9529 because the PR returns the full DN of the record it finds. So if it finds a user in a sub-OU it will return the full path including the sub-OU. So that's all good. 👍

The point about 5 -6 could be solved by adding a "AUTH_LDAP_DEFAULT_ROLE_ID" like the OAuth and OpenID providers. If that config option is enabled, we would just ignore LDAP groups entirely.

[aidenfoxx]

You can also configure multiple LDAP logins on a per-department basis if that is any better for you, each with differing configs. Something to keep in mind.

[droptablespace]

Sorry my bad, In initial pull request, I missed

- resolve(`cn=${userCn},${userDn}`.toLowerCase());
+resolve(object.dn.toLowerCase());

Part which solves my points: 1-3.
Points 5-6, I presume, are not so important to add completely new driver.
I'll definitely test new driver's version(to my understanding it should work like a charm)
I suggest closing this proposal for now. Thank you.)

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.