search

ory / kratos

The most scalable and customizable identity server on the market. Replace your Homegrown, Auth0, Okta, Firebase with better UX and DX. Has all the tablestakes: Passkeys, Social Sign In, Multi-Factor Auth, SMS, SAML, TOTP, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
https://www.ory.sh/?utm_source=github&utm_medium=banner&utm_campaign=kratos
Apache License 2.0
11.34k stars 964 forks source link

LDAP authentication #274

Open raffis opened 4 years ago

raffis commented 4 years ago

Describe the solution you'd like

I would like to see the possibility of ldap authentication. Following points should be considered:

Options:

Additional context https://github.com/go-ldap/ldap

aeneasr commented 4 years ago

LDAP as an up or downstream? Meaning that we should allow LDAP as an identity pool for Kratos, or that Kratos is able to become an LDAP server?

raffis commented 4 years ago

Well the seccond would be awesome but I don't really see a point in that since ldap is quite complex and there are already pretty good ldap servers out there.

Kratos should be able to talk to one or more external ldap servers to authenticate users.

aeneasr commented 4 years ago

Agreed - tracking but with an undefined milestone as we have to get other things done first.

raffis commented 4 years ago

Usually big enterprises have existing ldap infrastructure and I would like to see a kratos/hydra construct which can authenticate users against it.

raffis commented 4 years ago

If I have some spare time I can look into this. But did not look at the kratos core yet in detail.

aeneasr commented 4 years ago

Cool! Contributions are always welcomed!

jiangytcn commented 4 years ago

that would a useful feature for enterprise. I'm evaluating the ory stacks, and now pending on this new feature to support existing ldap servers group.

aeneasr commented 4 years ago

Feel free to start a plan how LDAP integration could be implemented in Kratos, contributions are welcome!

danny900714 commented 3 years ago

Is there any further progress?

blufor commented 3 years ago

So, where do I begin...

Probably first with some background on this rather lenghty post. The reason for it is mainly my personality which drives me into practitiong what @jordansissel (author of Logstash) coined as ADD - Anger Driven Development :) And that simply lead me to the decision to put my spare time and hopefully further few lines of code to it.

So in this post I'll go through the currently rather troubled situation with open-source SSO/IDP, some kludgy options available at this time, key architecture questions about this feature that need to be covered and options to be selected. I'll do my best structuring it so we can start constructive discussion probably on Slack. I've joined today, same nickname - @blufor - so you can contact me there. BTW That's the main goal of this post; to get things moving so the coding can start ASAP - while COVID effects still last and there's spare time ;)

There are some references to links and notes that further explain certain statements or provide more background. It looks like this [a].

SSO and Identity isn't new

....but it still sucks :(

I remember more than 15 years ago, I've been tasked with deploying and delivering Sun Access Manager to a customer [b]. Really massive enterprise piece of Java shit that is luckily already in silicon heaven. It supported LDAP as IdP and Kerberos as SSO.

Since then things have evolved, but rather in the sense of quantity. There are quite a lot of projects that provide both SSO integrations with standardized (cert, user/pass, and modern auth mechanisms. And not just paid, but also "freemium" (but sometimes free version lacks something you need) but also open-source. The problem is - almost all of them are in fsckin Java! [c].

But however those solutions might be, most of them provide login integration Kerberos and/or LDAP. And these two are gonna stay with us for some time. Many other services and tools integrate them and LDAP is generally a good battle-tested technology to be source of truth for identity verification and data lookup.

The Bill Gates conspiracy

The reson, why i think this feature should have its priority increased is the current reality. Lots of the people asking about it is Microsoft's good business model. The Active Directory has been (and still is) requirement of many companies, including startups. From my last 5 customers only 1 didn't have Windows Domain but that changed some time after I left and the company grew a bit more.

Why is that? Well, almost any successful company comes to a point when it has increasing amount of employees. And they need computers to work on. From what current market offers, Microsoft has been winning for a long time, so far thanks to lower price [d] and the capability of managing the machines centrally, which gives them ticks for certifications in future and is overall more complete solution (quality aside...).

Now one Win Server license also hasn't been that expensive either. Plus for some time, you have their sales reps massively pushing their Cloud services with crazy initial discount (I've heard of 0$ bills up to 1yr). Those Cloud services of course integrate with on-prem Active Directory nicely. So compared to Google offerings, you're getting the same services basically, but M$ also packs workstation management in it. Like it or not, it just simply is a complete package.

[e]

Current Golang LDAP integrations

Authelia

Really neatly looking Go app with significant backing that integrates a lot, however the OIDC provider is still WIP. Anyways their LDAP integration in Go might serve as a point of reference [_ldap_connectionfactory.go, _ldap_userprovider.go]

Uses go-ldap/ldap/v3. Looks like it uses Redis (and maybe more) to cache of selected LDAP fields of user objects [link]. Also seems like it provides flow to reset password (not sure it covers LDAP)

Werther

Identity Provider in itself that uses LDAP as data backend for login identities. Supports Login and Consent flows only. Has UI, integrates with ORY Hydra. Basically looks like Kratos with fewer features and added customizable UI (go-template)

No updates for some time, however recently got updated with go-ldap/ldap/v3

Feature proposal

What

How?

Some of the previous crucial points need some further decisions to be made and I'd love ie @raffis or @aeneasr to voice their opinions and thoughts.

Create model for connection configuration

Questions:

Somehow implement syncing the data from LDAP to Identity traits

This one is probably the the most work to be done.

First let's talk about syncing in itself. The necessity of a way of linking the data from LDAP is undisputable. Than means that some sort of unique LDAP identifiers needs to be saved into the Kratos Identity Object. However LDAP is quite often used as configuration tool for authorization by using group membership. This often changes and those changes need to be refrected in the identity traits. Most of the implementations I've checked (Keycloak, Authelia, Gluu,...) have some sort of background syncing. There are two approaches:

Each has its own treats:

The first one obviously becomes a problem with large user bases. Can be mitigated a little by using multiple Kratos instances, each with different seach base to do a sort of "sharding". Also maybe it can possibly be implemented outside of Kratos and doing the updates via API.

The second one wouldn't grow so rapidly and the periodic data sync could be linked to each account separately, providing equal distribution of sync interval starting points (based on identity update time) across the user-base. This would mean at least +1 a sync goroutine for each LDAP linked account...

Regarding the RFC3062 password modify - It certainly would be nice, however I don't think it really has a high priority. As mentioned - having LDAP usuallu means having coverd management SOPs, like password change, or generic attribute update (surname + martial status, home address, gender...). The latter is IMHO out of scope of Kratos... but I might be wrong

Questions:

Registration using first LDAP auth login

This would be valid only when not using/implementing the full sync pattern. Othewise, all of the identities would be created/linked to existing ones during the first LDAP sync.

Questions:

Notes:

[a] Hello world

[b] The customer...

...was an office of regional district government in CZ - AFAIK besides governments and global corps in IT, banks, insurance etc, nobody was even considering SSO, mainly because mostly of absent knowledge about security and also the amount of $$$ required back around 2005 in the post-Soviet-bloc parts of Europe.

[c] Java...

...not that it would be bad in itself. It's a great language and VM to efficiently execute operations. However the problem here IMO lays with the ecosystem's long history and its community.

Don't get me wrong - there's a great Java software being made now, look at Elasti.co and their products. It's a breeze to run, operate and maintain. So there must be great Java coders - yes, the reason is in the people creating the software and their culture, policies... On the other hand, look at Jenkins with its massive load of plugins in various deprecation state and bugs in the lots of the remaining ones. The culture of that project is at least questionable.

But if you go deeper, you realize, the problem lays in the sheer scope of what Java provides, the amount of frameworks, protocols (who likes XML + SOAP these days?) and then even languages that JVM can run (like Groovy, Kotlin, but also JRuby, Jython etc.). The immense ammount of complex libs sandwiched together by coders with varying skills into one app can't well in most cases. This obviously relates to one of the longest histories paired with probably the largest subset of people using any programming language.

Now put that image next to Golang, which compared to is Java very new, designed for specific target group to cover mostly basic needs like memory management, concurrency, data handling, system level stuff, network or basic protocols; mainly in an efficient way. Yes,, it took some time to come up with a final proper way for lib management, but the community already brought some cool modern things like oauth, fido, but also Docker, all the Hashicorp stuff, etc.

Which brings us to the alignment of those two narratives, and it's the culture, I don't know how to specify it, some quotes here and there on the website, in tickets... somehow reminds me of the Tao of Hashicorp and I'm absolutely aligned with that philosophy.

NOTE: I have no relation to any of the companies or products mentioned, Just various degrees of experience with using the free/OSS software.

[d] Let's see how Apple stirrs up the market in some time

[e] One more great example...

AD is also packed with RADIUS and CA. Each user and computer has their own cert-key pair and I love to config the companies' network with 802.1x TLS auth on both Wi-Fi and physical network. Each employee always dynamically maps to his VLAN, which is part of a network security zone. This is also mapped via LDAP group membership. And all major network hardware vendors support it without any plans of dropping it. More focus regarding security in those common features is rather on low-lat performance with larger ciphers.

aeneasr commented 3 years ago

Hello @blufor and thank you for the insightful post. Could actually become a blog post? @vinckr could help bring it on the main website so your work isn’t forgotten i. the thousands of github comments!

Also sorry for my short answers - but I’m on mobile for holidays ;)

So first of all we’ve been pushing LDAP back because we didn’t really want to deal with AD and all that stuff. But it’s great to have you here - you did your research and have knowledge- so it looks like there’s no better time to start working on this!

I think the user sync model is nicer - easy to shard (and scale), less work for Kratos - no user filters, and so on!

I imagine the syncer to be a worker like „kratos courier“ which makes it (a) optional and (b) easy to scale and (c) easy to configure using e.g. CLI flags.

For OIDC we merge fields from the POST request (e.g. user consents to ToS) with data from OIDC which is first run through JsonNet for modification. The code for this starts here: https://github.com/ory/kratos/blob/master/selfservice/strategy/oidc/strategy_registration.go#L9

We thought about system level traits but have not implemented them yet. However, adding those would be easy. One question is if we have them in traits or be part of another field (e.g. meta). This probably needs the most thinking!

Alternatively we could also just disable the settings flow for those users? As we would disable other flows too (verification, recovery)?

After thinking about this a bit more: It sounds to me as if all we want here is for a user to exchange their LDAP credentials for a kratos session token? Given that we don’t want registration, recovery, verification, profile updates?

How does 2FA work with LDAP?

vinckr commented 3 years ago

Awesome thread!

@aeneasr Could we reformat/expand it a little bit and then publish it under @blufor's name on our blog? So he gets all the credit for this writeup; I would feel bad to just copy it and put my name there 😅 .

Happy to take care of all the stuff around publishing it, just want to know if you are up to it and if that is generally something we would do?

aeneasr commented 3 years ago

That was the idea :)

Riz-waan commented 3 years ago

So just curious, would I be able to use my Kratos users and connect a few of them to LDAP, but Kratos being the origin of the accounts? Not sure if it makes sense. Let me try to clarify. Let's say I have a Kratos instance for all my users. A set of those users are employees who need to work with LDAP applications. Is there any way I could use OpenLDAP the same way as something like Hydra, where main user authentication is handled by Kratos. Also, my understanding could be completely flawed, as I just started learning about this stuff.

aeneasr commented 3 years ago

Currently we have no such capabilities in Ory Kratos. I think what this issue refers to is to use LDAP as an upstream provider (like "Sign in With Google") as most companies use e.g. Azure AD for their employee management.

Your proposal would also work, it would mean that Ory Kratos becomes an LDAP server. So instead of issuing tokens or cookies, you could do LDAP queries against Ory Kratos.

Both features are currently not available though.

haslersn commented 3 years ago

Given that we don’t want registration, recovery, verification, profile updates?

@blufor @aeneasr If you don't want all of that, then what would be the remaining advantages of Kratos over Werther? Session management (including logout) and 2FA/MFA?

I think for a good user experience it's important to have a single UI where all account-related things are managed, i.e.:

Of course one can write a UI that has access to both the Kratos API and the LDAP API in order to use the right API for the right task, but I think it would be nicer if the UI only needed access to the Kratos API. Using both APIs would also lead to sync issues, i.e., a user updates something that is done through the LDAP API and this is not immediately synced to Kratos.

I think registration and verification can indeed be left out for now, since in enterprises registration is typically done by admins who can use another UI for administrating the LDAP server.

strazto commented 2 years ago

@blufor this would actually be a great blog post ("Quantity over quality - The problem with the evolution of modern SSO" or something) and I'm very happy to see someone acknowledge the clusterdump that is these java based IAM systems. I thought I was crazy for thinking keycloak actually kinda sucks, because everyone seems to love it

Pramodamrutkar commented 2 years ago

Is there any further progress?

neutronth commented 2 years ago

I try to implement this in [1], based on v0.10.1 It's a dirty hack and still lack of code quality, there's no proper code testing and no integration test with kratos-selfservice-ui-node yet, some of code have been copied and pasted from the neighbor strategy, password/oidc, and may not correct implemented.

I did a local integration test with a prepared LDAP (389DS container), it works at least for my expectation. Hopefully, it may be useful for someone looking for the solution.

[1] https://github.com/neutronth/kratos/tree/strategy-ldap

zambien commented 2 years ago

@neutronth this looks to be a really good starting point for LDAP integration. I've been thinking about creating a sync pipe between LDAP and PostgresDB using PingDataSync (not OSS) or some similar tooling but it would be really nice to be able to use LDAP as the backend. I'm going to play around with this.

lermana commented 1 year ago

Hi @neutronth and @zambien, happy new year to you both! Thank you for the amazing Ory platform - it's a really key addition to the space. I wanted to ask whether the LDAP integration was something you're actively working on, as this would definitely be of interest to my team. Thank you.

dhia-gharsallaoui commented 11 months ago

Hello :wave: We are very interested in using LDAP as a backend. Is there any ongoing work or a foundation where we can contribute to adding this feature? Thank you.

irisitymichaelgrundberg commented 10 months ago

Same here, we have a project right now that requires authentication of users that are defined in our customer's on-prem AD. Since we currently use Kratos as authentication backend, it would simplify our architecture if Kratos could talk to the AD using LDAP.

However, we would still require some identities to be created in Kratos, for administrator access in case the connection to AD is down.

We would be willing to contribute with time and code to get this implemented.

dhia-gharsallaoui commented 10 months ago

Same here! However, it might not be a good idea, or the current architecture may not be compatible with LDAP. If that's the case, could someone please explain it to us?

renom commented 10 months ago

Any plans to implement this?

irisitymichaelgrundberg commented 9 months ago

We have successfully applied the "hack" mentioned in https://github.com/ory/kratos/issues/274#issuecomment-1236057606, on top of Kratos v1.0 and it's working fine using OpenLDAP. The goal is to be able to use it in production in a few months, for a customer using Windows Server AD. We also need to have accounts using password strategy in parallel to LDAP strategy (for administration in case the LDAP connection is not working).

@aeneasr It would be nice if we could make a contribution back into the Ory product regarding this, to not have to maintain our own fork of Kratos. Could someone in your team provide any feedback on whether the previously mentioned "hack" is a step in right direction regarding how LDAP integration would be designed? And also provide any feedback what else that should be done for this to be acceptable into Kratos?

jbguerraz commented 9 months ago

Nice @irisitymichaelgrundberg ! :+1: @aeneasr any input on the matter ? what the community should do with this ldap support ? we're also open to provide time to contribute, we could start from @neutronth's implementation and move it torward release! what do you think ? any chance that would be suitable ? Thank you!

dhia-gharsallaoui commented 6 months ago

Any update on this? @irisitymichaelgrundberg , do you mind sharing your fork, please?

vinckr commented 6 months ago

Thanks for the comments everyone.

At the moment there are no plans to implement LDAP functionality in Ory Kratos .

If that should change at any point, we will send an update in this issue!

Right now I think a third-party solution like Werther for Ory Hydra would be best solution IMHO instead of maintaining a fork.

irisitymichaelgrundberg commented 6 months ago

@vinckr We have already implemented LDAP in our own fork; it was a quicker way than modify all of our frontends to use another authentication provider.

@dhia-gharsallaoui Since we did not get any response from Ory regarding how to develop LDAP integration to be acceptable into the main Kratos repo, we developed it to just suit our needs. However, we put it in a public repo if others want to look at/use the code: https://github.com/AgentVi/kratos/pull/1/files

vinckr commented 6 months ago

Thanks for sharing Michael! I will follow up here once I know more.

dhia-gharsallaoui commented 6 months ago

thank you for sharing @irisitymichaelgrundberg :pray:

quintilation commented 3 months ago

We have very simple requirements for AD, just two APIs validate some users credentials against AD (based on a special Public Metadata field), this would return updated UserID, Email, account Active flag, and Real names (Identity.Traits) from AD fetch the Account Active flag by UserID (i.e. ensure the account has not expired or been revoked)

I am happy that I can write code to authenticate and extract the traits from AD.

If we had a way to describe an external credentials validation service in kratos.yml I could implement this as a REST api returning jsonnet

This would look very similar to how oathkeeper communicates with kratos at present.

would such changes be simple enough to be acceptable to Ory - no increasing the support workload significantly, but allowing third parties to implement their own custom credential validation service.

Thoughts?