Authenticate against an LDAP server

[JustSomeHack]

Support authentication via an external LDAP connection

Problem

We have users that exist in LDAP or AD and we want to use FusionAuth as a primary IdP but still authenticate some users against an existing LDAP server.

Solution

Support an LDAP authenticator.

Proposed solution for the initial LDAP connector support:

Use Case 1

I want to authenticate some users based up on their email domain, or otherwise selected users in FusionAuth against an external LDAP database.

1. Call the /api/login endpoint
2. FusionAuth looks up the user by loginId (email or username) and identifies if they are *eligible for external authentications.
3. Make an LDAP request and send along the email address (or login Id) and password
4. LDAP returns with an authentication response
5. FusionAuth completes the login

Use Case 2

I want to authenticate some users based up on their email domain, or otherwise selected users in FusionAuth against some other generic system or database.

This use case is nearly identical to User Case 1, however instead of the remote system being LDAP, it could be a MySQL db that contains a user table, or a legacy 3rd party "thing" that has no external API, is not LDAP, etc.

For this use case, we would build a "generic" external authenticator. FusionAuth would expose a mechanism to define a URL, define headers, etc to enable a secure connection.

FusionAuth would send a defined JSON request to the configured authenticator that would likely be identical or similar to the Login API request body (example):

{
   "applicationId": "d50a0d3f-ea14-41cb-b427-8d6eccbc10c3",
   "loginId": "bob@acme.com",
   "password": "my super secret password"
}

You would write a simple request handler to consume this JSON, perform the authentication step which. may be looking up a user in a db, hashing the password and comparing, or whatever black box work you need to do in order to identify this user as authenticated or not authenticated. Then you would return with a 200 or a 401 or 404 with a JSON body describing the User.

FusionAuth would then complete or fail the login.

1. Call the /api/login endpoint
2. FusionAuth looks up the user by loginId (email or username) and identifies if they are *eligible for external authentications.
3. Make a request the the configured "external authenticator" and send along the email address (or login Id) and password
4. FusionAuth consumes the response from the external connector
5. FusionAuth completes the login

• Eligibility could be calculated based upon email domain, individual configuration, or other TBD mechanisms.

If we solve this use case, I think that may satisify this other open issue https://github.com/FusionAuth/fusionauth-issues/issues/232

Not covered by this solution

Use Case 3

I have devices, or applications that can only authenticate against LDAP. I want FusionAuth to be revealed to these devices as LDAP.

For example you may have a printer, wifi access point, etc that may use a Radius server which can authenticate against LDAP. You may have linux clients (servers or workstations) that can only authenticate against LDAP / OpenLDAP.

This is a separate use case from Use Case 1 and Use Case 2 and is not currently in plan. Please comment in the thread below which Use Case you are looking to be solved - if one or the other. If you're looking for both 1 and 3, include your priority in order.

Opened up https://github.com/FusionAuth/fusionauth-issues/issues/954 to track this use case.

Alternatives/workarounds

Write some glue code to authenticate against LDAP and then build a JWT that you can use to reconcile with FusionAuth use the External JWT IdP API.

Additional context

?

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

Thanks @JustSomeHack - do you have any specific examples of when you cannot use AD (via federation with OAuth2 / OIDC) and what versions / vendors of LDAP you encounter in these scenarios?

[JustSomeHack]

In general, clients offer us direct connections to the LDAP backend, most are AD and others are OpenLDAP.

[robotdan]

@JustSomeHack We do offer pro-serve as an option for this type of feature. DM me on the FusionAuth Slack channel if you want to discuss the project requirements, that will help me give you a better estimate on time and cost.

[archontech86]

I am also interested in this. LDAP is a core capability in identity infrastructure today. the inability of fusionauth to integrate with LDAP kills the capability of using this product as a serious contender in the identity space.

on the pro side it appears that your UI and modern auth capabilities are very clean and inline with open standards. +1 to you guys for doing good work. This would be a good replacement capability for our existing IDP if it simply was able to check passwords\identity attributes with backend native directories in the market today over the LDAP protocol.

[robotdan]

Thanks for the feedback @archontech86

on the pro side it appears that your UI and modern auth capabilities are very clean and inline with open standards. +1 to you guys for doing good work.

Thanks!

LDAP is a core capability in identity infrastructure today. the inability of fusionauth to integrate with LDAP kills the capability of using this product as a serious contender in the identity space.

There is certainly a portion of the market that needs LDAP, but there is also a very large portion that does not. FusionAuth is not an Active Directory competitor, we focus more on customer (or end user) identity management. In this space the LDAP complexity and feature set is not as desirable, and scale and performance are paramount.

Adding LDAP could make FusionAuth appealing to those who still rely heavily upon LDAP but in a general sense those that are primarily using LDAP, Active Directory, Oracle Id, etc - are not our target market. We tend to deal less with employee login and more end user - although there is always some overlap which is why we support federation to SAML v2, OpenID Connect, or anyone that can generate a JWT.

One option we've discussed is to add a generic external authentication request API that could be used to support LDAP, or whatever else a client may need supported. See https://github.com/FusionAuth/fusionauth-issues/issues/232 for additional information.

We do offer paid support contracts with pro-serve options to build out features to meet a particular client business requirement. That is to say if someone wants this feature enough to pay for it, we'll build it.

[archontech86]

@robotdan Thanks for your reply!

I understand not wanting to be direct competitors with directory providers. I appreciate the idea behind #232 however most of those issues would in fact be solved by simply adding LDAP (which is a protocol spoken by many many applications not just directory providers) as an available communication language to the stack of great languages that are already supported by your software stack.

When most people hear LDAP they do think that people tend to be meaning directory replacement which in fact communicating with existing architecture helps make your offering more attractive. Many application developers are using back end application or software defined directories withing AWS or deploying them virtually in zero trust environments that rely on existing user sources. Those user sources nearly always speak LDAP at a basic level whle IDP software can translate that into a more modern protocol such as OpenID Connect SAML or OAuth. Take a look at Okta, Ping Federate, Gluu etc. All of these at a core level have the ability to speak back to an LDAP directory elsewhere.

The truth is that IDPs that want to be able to provide true SSO capabilities need to be very flexible with the protocols that they are capable of speaking as to support as many back end sources of informaiton as possible.

I understand that this may not be what your interested in targeting, but it is a shame to see that the roadmap does not align with where the industry appears to be heading.

[robotdan]

Thanks @archontech86 I do agree that LDAP is pervasive.

If we were going to build FusionAuth to sell to enterprise to manage their employees, IT infrastructure etc, no question we'd build LDAP for compatibility and interoperability. A directory makes perfect sense for this use case, a company naturally has hierarchy, departments, etc.

Instead we built FusionAuth for developers who are building applications with end users, not employees. The needs for this target audience are different and while we could have wraped an LDAP service with a REST API we chose not to do that. We did not want to be encumbered by architecture choices made over the last 25 years that may or may not be relevant in the modern age of software development and security practice.

We do offer federation to ADFS, SAML v2, etc so that we can offer some overlap where employees from one company may be end users for another company using FusionAuth or a portion of employees that need to be able to use their same account to log into an end user facing application.

So it isn't that we don't want to compete with directory providers, we are simply solving a separate problem. This means in practice we are rarely in a competitive situation with a directory provider. M$ AD, Ping, etc are generally sold through the IT side of the business, (CIO, CISO etc), where we would be working more with application developers, CTOs or R&D.

We do have different perspectives and that is ok. I appreciate the feedback and your insight.

[JustSomeHack]

Thanks @archontech86 I do agree that LDAP is pervasive.

If we were going to build FusionAuth to sell to enterprise to manage their employees, IT infrastructure etc, no question we'd build LDAP for compatibility and interoperability. A directory makes perfect sense for this use case, a company naturally has hierarchy, departments, etc.

Instead we built FusionAuth for developers who are building applications with end users, not employees. The needs for this target audience are different and while we could have wraped an LDAP service with a REST API we chose not to do that. We did not want to be encumbered by architecture choices made over the last 25 years that may or may not be relevant in the modern age of software development and security practice.

We do offer federation to ADFS, SAML v2, etc so that we can offer some overlap where employees from one company may be end users for another company using FusionAuth or a portion of employees that need to be able to use their same account to log into an end user facing application.

So it isn't that we don't want to compete with directory providers, we are simply solving a separate problem. This means in practice we are rarely in a competitive situation with a directory provider. M$ AD, Ping, etc are generally sold through the IT side of the business, (CIO, CISO etc), where we would be working more with application developers, CTOs or R&D.

We do have different perspectives and that is ok. I appreciate the feedback and your insight.

I don't think anyone is asking for FusionAuth to manage any employees are user accounts. It's the ability to use LDAP as an authentication provider. We're basically asking for the same abilities as ADFS or SAML v2, but for LDAP. Pass the authentication through to LDAP.

I'm currently building out some projects for some clients and would like Oauth2 integrated, but customers... who are not enterprise have their users in AD, which essentially is just LDAP. When you talk about ADFS, that's more enterprise then you can get. Unfortunately without LDAP, we're forced to look elsewhere as most customers don't want another place to manage their users, they just want to use what they currently have.

After all, this is just a feature request, it ultimately is your decision to implement or not. I do like FusionAuth for the user interface and stability, but without LDAP, I just can't use it. We have a startup of 5 employees and use LDAP to centralize authorization. If you feel that this is not part of your project plan, then go ahead and close this request, and we'll move on from here.

[robotdan]

@JustSomeHack

My comments to @archontech86 are to provide some background for why we did not build FusionAuth on top of LDAP and why it has not yet been a priority to add as a core feature.

I do think there is value to add LDAP as another Identity Provider configuration to make FusionAuth more accessible.

Thanks!

[cryogenx]

would also love to see this have LDAP, I've been researching several ways to provide a SAML endpoint for multiple active directory domains for users across several organizations to be able to authenticate to a central systems we have in place. The Application support a SAML2 auth provider but only one. I need to be able to authenticate user across multiple disparate domains. So I need a middle-ware to provide not only the SAML endpoint but the passthrough to LDAP for the actual auth part and I had seriously hoped this would be it as you have the cleanest user interface I've found in the open source arena.

I hope you definitely consider adding LDAP as an Ident Provider for authentication at a minimum.

[terafirmanz]

Would love to see LDAP as well, however rather than implementing a hook to auth via an internal system API for some users. I think a sync engine e.g. the scripts provided for migrating to FusionAuth run periodically would solve this and be more extensible/scaleable.

Something like, in admin section an identities import screen where yo can define external identity stores and jobs to schedule importing them. From there you can then build standard providers e.g. LDAP, SQL and the admin can use them to connect to the external provider and import changes (new users, remove old users, update user details). You would then map the attributes and the password hash would be imported and stored along with the attributes

This would be similar to how Azure AD Connect works by importing attributes and password hashes to allow for SSO.

[masterclock]

After several days of tries and tests of FusionAuth and KeyCloak, I choose KeyCloak. I prefer everything of FusionAuth to KeyCloak except for lacking of LDAP IdP.

[robotdan]

Thanks for the feedback @masterclock , thank you for taking a good look at FusionAuth. Be sure to upvote the issue if you haven't already, this does help us direct our resources.

[robotdan]

How many on this thread would be up for doing minor coding to support this use case if we finished this feature? ( https://github.com/FusionAuth/fusionauth-issues/issues/232 )

[soullivaneuh]

I second @JustSomeHack demand. As a host provider, we are also testing FusionAuth to have a centralized authentication to our customers and employees to access to multiple services.

We currently have one LDAP server for internal use only.

The goal is to have LDAP using FusionAuth, and then we will have only one platform to manage all our accounts.

I hope the case is clear enough, tell me if you need more details.

[sbingram]

Such a shame considering the framework support of FusionAuth, but we are too looking to go with Keycloak everywhere due to the lack of LDAP in FA. I understand that none of the app consumers will need it, but internal user stores are sitting in AD or other LDAP directories and have no intention of setting up a separate identity in FA. Keycloak even allows users to update their directory password too so resolves several internal support issues as well. It would be really nice to have that bridge.

[a1730]

First thank you for a great project(product).

We could also use a LDAP provider of some sort.

We have a "legacy" application that leverages LDAP for authentication and authorization, and we really, really wanted to use FA. We looked hard at FusionAuth, and tried even harder to make it work but it failed. We were able to shoehorn authentication to FA by using dexidp/dex as OIDC provider for FA(We wanted pre-baked multi-tenacy) but issues bite:

0. Our developers love FA. Our future plans include FA (still).
1. We are managing three services (FA, Elasticsearch, and dex). If FA supported LDAP directly, we would gladly turn off Elasticsearch and get the important reports from LDAP.
2. The "legacy" application has a lot of fine grained permissions that our JWT was getting ridiculous in size. We dream of future state using FA with LDAP backend for authentication, MFA, multi-tenancy, and all the excellent authn features in FA BUT keep authz on LDAP. We are very comfortable managing authz in LDAP realm. By the way, our application is a middleware talking to our customer's customer users (Walmarz users) on one side, and our customer's partners (delivery agents) on the other. Think of a supplier to Walmarz - Walmarz users use our platform to order items from our customer for delivery to a potential third party.

0.0: We love FA and what we are reading about your future direction. Keep up the good work.

Thank you.

[socialcyberdog]

One more. Seems absurd for me not to support LDAP backend for this product.

@robotdan: thinking about LDAP as "employee database" is an artificial limitation of your potential use cases, I feel a strong lack of vision here - it is used as a de facto user db standard in many places. "Ldap = inhouse employee db" is thinking from the last century and has nothing todo with wildly distributed / integrated / cloudified infra of today in many places.

It is just "users" nowadays. They will use endpoints of your infrastructure, be it a Django, PHP or Elixir app, some piece of your infra, some backend api, some apps of your K8S cluster, some endpoint anywhere in your "cloud", some VPN, maybe some IOT hardware or some service inside some remote vehicle. Some "users" are employees, some are customers, some are both, some are "partners", some are just other computers.

[robotdan]

We appreciate all feedback and opinions.

Business use cases and other real world justification for this feature are welcome.

Words like absurd and lack of vision are not constructive in this forum. Please do you best to keep comments constructive so we can have a healthy conversation about future direction of FusionAuth.

Thanks for using or considering FusionAuth.

[irzhywau]

@robotdan Is there any workaround to implement such flow actually with existing integration features?

[robotdan]

@irzhywau you can build a small compatibility layer to interact with LDAP and produce a JWT to use with the ExternalJWT IdP.

[irzhywau]

@robotdan I tried to implement such an alternative but it just led me into a deadlock and seems not to be relevant for our use case. The feature we wanted was mostly authentication, 2FA, password recovery but relying on an Open LDAP server as the source of user's credentials and other info. All of these are well supported within fusionauth I think. But by using external JWT, we have to implement ourselves all the 3 features we need: a login page that flows into the built-in OAuth as you don't provide a button on your login page, a new interface to manage user settings, etc...

Maybe you guys should really consider implementing something that can play a role of an adapter at least so that people can develop the business logic of what they want from their side and keeping the usage of all the features inside of fusionauth, kind interface that we can implement ourselves

[ZaxLofful]

My two bits:

My scenario is that I want to be able to manage my Windows/Linux machines with FusionAuth to control both the login process and access to file shares/etc.

Right now I would basically just have to create a Windows/Linux LDAP domain and join my machines/users to that for management of the device login, then sync that data somehow into FusionAuth; as your product only really allows me to use it for websites and such. I want FusionAuth to be my source of truth and allow me to join machines over the internet to my domain.

I am attempting to replace AAD/JumpCloud, but this is my current limitation.

Right now I use JumpCloud, but I can only have 10 users. I am looking at FusionAuth to replace it, but have the listed domain/LDAP issues for the machines themselves.

[robotdan]

Thanks for the data points @ZaxLofful. Since you only have 10 users in JumpCloud I'll assume you're on their free plan.

To be transparent, if we build this feature it will almost certainly only be available in a paid edition of FusionAuth. There are many reasons for this, buy me a beer and we can discuss that part further. :-)

The primary question to anyone on this thread that wants to see LDAP support is; would you be willing to purchase a paid edition of FusionAuth get LDAP support. Or are you only interested if it is in the community / free edition.

Feel free to answer this question as a thumbs up or down on this comment.

[terafirmanz]

Thanks for the data points @ZaxLofful. Since you only have 10 users in JumpCloud I'll assume you're on their free plan.

To be transparent, if we build this feature it will almost certainly only be available in a paid edition of FusionAuth. There are many reasons for this, buy me a beer and we can discuss that part further. :-)

The primary question to anyone on this thread that wants to see LDAP support is; would you be willing to purchase a paid edition of FusionAuth get LDAP support. Or are you only interested if it is in the community / free edition.

Feel free to answer this question as a thumbs up or down on this comment.

Would click the thumbs up but it didn't express how much I would be happy to pay for a premium version that had features like this. Even more so if it could go as far as JumpCloud does in replacing AD.

Also acting as a RADIUS and LDAP server for external clients in addition to SAML etc. would be amazing.

[ZaxLofful]

I am willing to pay for a premium, if it will replace JumpCloud for me entirely. My biggest and only real concern is the pricing, because the main reason for me to want to go away from JumpCloud is the amount of users versus the price.

If I could get a yearly license that is all features and unlimited users, I would be interested; but not if the price is on a per-user basis.

I want to run fully self-hosted and the pricing model of per-user is the biggest and only real problem I have and hence why I am trying to remove the JumpCloud dependency.

I would recommend implementing it like OpenLDAP or Apache LDAP; and it could done cheaply and allow for an easily scale-able user base. I am experimenting with a combo of these techs, plus an actual Microsoft Domain; but I would love a single solution.

Edit: Is there an API for FusionAuth? I could try and import then janky code I have now as a plugin and test it for ya'll....

[buzzware]

+1 for LDAP authentication, and reading of user roles, name etc. For a current project, the customer company have an Active Directory server with users already setup. I just want something to receive user name and password, then return a JWT or not. Can I use another protocol? I don't yet know what version of Windows Server they have, or what protocols it supports, but LDAP is what everyone talks about. As this doesn't seem done yet, I'll keep an eye FusionAuth, but it's a deal breaker for now.

[cubic3d]

@robotdan I see it has been added to the 1.17.0 milestone. Will this be available in the community edition?

[robotdan]

The current plan is to make this a paid only feature per https://github.com/FusionAuth/fusionauth-issues/issues/219#issuecomment-601248051

[Kkeller83]

So you are taking the same route in the end as Gluu with different editions.

And this statement will not apply anymore ?

With Gluu you will need to upgrade to their VIP or Enterprise packages to unlock additional high availability functionality, two-factor authentication features, and vulnerability notifications.

FusionAuth takes a different approach. We provide our complete platform with no premium tiers, no enterprise-only features, and no sacrifices. You can download and deploy the entire platform with access to every feature with no restrictions, licenses, or barriers regardless of how many users you have. Whether you deploy it on your own servers or take advantage of our FusionAuth Cloud managed hosting you get every feature and function of the entire platform from day one. You also get all future upgrades, features, and patches without any additional fees.

[Kkeller83]

I understand of course, there needs to be some revenue stream. Just wanted to get it clearifed. Furthermore, if I may, I would have rahter loved it , if you had some sort of plugin marketplace and just take a cut of every purchase. i.e. this could be an ldap plugin that we pay for via one time payment of subscription. Thing is, I would probably rather build a python script to sync my ldap with fusionauth via rest then buy a full fusionauth subscription before I have enough revenue in my small business to afford it for one feature. Or I would just go with the Okta developer tenant for 1000 MAUs etc. or Startup package to buy me some time.

[cubic3d]

@Kkeller83 What's wrong with Keycloak?

[Kkeller83]

Yeah, good idea.

[martijnraats]

I must agree that it is not nice to read on the website:

Use FusionAuth for Free Seriously … No tricks or gimmicks! Download FusionAuth -- the full version, not a feature-crippled 'developer' version -- deploy it on your servers or private cloud, and you can use it for free for as long as you need. No time limits, no user limits, no restrictions. Use it for local testing, proof-of-concepts, in-house development, MVP startups, or full production. No problem.

To then find this issue and read a feature is only in a paid version.

[robotdan]

Thanks for the comments @martijnraats and @Kkeller83 , we do appreciate all feedback, however please keep comments on this thread on the topic of the technical requirements for LDAP.

Our intent is not to be deceitful. We have started to add some paid features in FusionAuth. We are updating some of our language on the main site to reduce this type of confusion or surprise.

For this feature particularly, the request was made by a community member. We of course have no obligation to build this feature at all. I asked if anyone wanted this feature enough to pay for it in this comment https://github.com/FusionAuth/fusionauth-issues/issues/219#issuecomment-601248051. The response we received was yes please!

I believe we are being very transparent in our intent to make LDAP support a paid feature.

Thanks, if you have any particular requirements for LDAP, please feel free to outline your use cases here.

As a side note, the human part of the support equation is the most expensive part of the paid edition. We are considering adding an additional tier above community, but below Premium which would include the paid features w/out support.

1. Would anyone be interested in that option? (Paid features , such as LDAP, but without support)
2. If so, what do you think a fair price would be? Premium currently begins at $500 / month and then goes up based upon MAU. Our current thinking is that we would charge a flat rate because our costs don't go up based upon MAU, but this is TBD.

Thanks for any feedback you have on this idea.

[mcronce]

I hate to be "that guy" but use case 3 is the one I'm looking for :)

[robotdan]

@mcronce the first phase will not cover that use case. However we'll likely be adding support for that use case shortly after based upon demand.

[robotdan]

Update from comment https://github.com/FusionAuth/fusionauth-issues/issues/219#issuecomment-625928513

We have added a developer plan which will include LDAP for those who do not wish to purchase an edition that includes support. https://fusionauth.io/pricing

[robotdan]

Initial support for LDAP connectors is in version 1.18.0. More LDAP features to come. We'll close out this issue and use separate issues to track additional LDAP features.

[mooreds]

@AkgunFatih sorry to hear that. Can you explain more? We want to make sure we're transparent about what is included in the community edition and what is not.

[robotdan]

I hate to be "that guy" but use case 3 is the one I'm looking for :)

Ha, we like that guy.

Opened up https://github.com/FusionAuth/fusionauth-issues/issues/954 to track the third use case described here that was not covered by this deliverable.

[xargi]

Oof, pushing this (the whole Connectors feature) behind a 125$/month license completely kills FusionAuth as an alternative for e.g. Auth0 for nonprofits and other small organizations moving off of existing legacy identity systems. I thought it was included in the free license after seeing it in the UI, but apparently not... Nothing indicates otherwise either.

[robotdan]

You're correct. the Connector feature requires a licensed edition of FusionAuth.

I believe Auth0 starts at $130 w/ LDAP w/out any internal users, many restrictions and rate limits, and the cost goes up quickly from there based upon your requirements.

We want to make FusionAuth accessible to everyone, and in order to offer FusionAuth for free we do have to ensure we entice enough of our users to pay us something for our work. While this may not fit into everyone's budget, in our estimation $125 is extremely competitive.

Thanks @xargi we appreciate you considering FusionAuth.

[xargi]

Auth0 starts at 23$ for 1k MAU for lazy migration from an existing data source, including infrastructure. I'll be glad to update further once I hear from their nonprofit team. Thanks for the reasonable response though.

[robotdan]

Auth0 is much larger, so it is possible we will not be able to match their price if they reduce it heavily for you. But feel free to reach out to sales - at - fusionauth - io as well, it is possible we can work with you on price. I do know we get a lot of Auth0 converts, and the primary reason is price, perhaps this does not reflect any special pricing they offer non profits.