[HN Gopher] lldap: Light LDAP Implementation
___________________________________________________________________
lldap: Light LDAP Implementation
Author : thunderbong
Score : 121 points
Date : 2024-07-12 16:54 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| will0 wrote:
| Funny that the L in ldap stands for lightweight, and yet clearly
| there is interest in a lightweight version of what has become a
| somewhat bloated protocol.
| ivanjermakov wrote:
| Ironically, there is not much "lightweight" in LDAP
| anyfoo wrote:
| You should have seen X.500.
| aidenn0 wrote:
| Did X.500 ever get even close to fully implemented?
| jdougan wrote:
| Rumour has it that that was logically impossible.
| kjellsbells wrote:
| Culturally impossible as well, in the sense thar x.500
| expected that every country's national telecom operator
| would take on the task of handling identity and certs for
| the population of that country.
|
| That said, the US DoD had a pretty good stab at it, and
| even today in corners of the defense industrial base you
| can find companies like Isode that still service that
| niche. To be fair, x.400 messaging and x.500 directory
| looked pretty smart back in the day when smtp and passwd
| were the alternatives. It's just that smtp grew up
| incredibly fast and quickly outstripped the alternative.
| jdougan wrote:
| I got my start in that era and they only looked smart if
| you didn't look deeply. Too many options, too many areas
| where they created a problem and then passed it off to
| someone else to fix.
| yencabulator wrote:
| It was simple _enough_ that back in 2002, I could implement a
| whole client+server LDAP protocol framework from scratch in
| ~11k lines of Python. That 's not _horrible_.
|
| ASN.1 gets a lot of (imho deserved) crap but it's roughly
| just a bunch of nested TLV (type, length, value) messages,
| just smeared with a bunch of legacy and a weird definition
| language. It's not all that different from e.g. Protocol
| Buffers. Outside of figuring out what context you're in and
| thus what message type an integer refers to, there's not much
| that would be "a hard problem" about it.
| Attummm wrote:
| Ah LLDAP (Light Lightweight Directory Access Protocol)
| danielfrg wrote:
| I use it for my home lab. Highly recommend
| NewJazz wrote:
| Does it do replication?
| Spivak wrote:
| No but also yes. lldap uses an rdbms as its backing data
| store so replicate the databases and point lldap at each one.
| ecef9-8c0f-4374 wrote:
| We had a forest of openldap trees in 2002. Openldap had a
| replication integrated. Slapd (its more than 20 years ago
| forgive me if I get things wrong). You could use a counter
| or timestamps to resolf conflicts. How do you solve
| conflicts?
| ecef9-8c0f-4374 wrote:
| My bad slapd is the openldap daemon.
| PeterWhittaker wrote:
| Hmm, shouldn't it be lSLAPD or LDSA? After all, it is an LDAP
| server, not lighter weight protocol!
| leshokunin wrote:
| Not to be confused with LDAC, the audio codec (which is what I
| thought of when I clicked).
| bityard wrote:
| I've been using this for the past few years. LLDAP + Authelia +
| Caddy is a great way to completely avoid writing your own (likely
| bad) authentication system. Layers are great.
| infogulch wrote:
| I've been wanting to build a stack like this. Mind sharing a
| few details about how you set it up?
| bityard wrote:
| Sure, here ya go:
| https://github.com/cu/silicon/tree/master/deploy/caddy-
| authe...
| oriettaxx wrote:
| my next task is traefik + authelia + ldap, and I will
| definitively try this lldap (openldap is really old style... )
|
| I'll do it in Docker Swarm: if anybody have suggestions or want
| to work on it together pls let me know
| SoftTalker wrote:
| OpenBSD also includes ldapd, a daemon which implements version 3
| of the LDAP protocol. It's simpler than OpenLDAP, at least since
| OpenLDAP started storing its configuration within itself.
|
| I don't think there's a portable version though.
| commandersaki wrote:
| In my teens I was obsessed with LDAP and shared authentication
| across a fleet of Linux machines, it sounded pretty cool. In
| reality I never actually had to administer or setup LDAP. It was
| popularised by Microsoft with advent of Active Directory in the
| 00s (I believe AD came out with Windows 2000 Server).
|
| Those days I didn't really understand the notion of a tree-like
| directory. Nowadays I'm think we're better served with a SQL
| queryable RDBMS to store directory-like data, and modernising the
| query language using JSON over a HTTP(S) transport.
| kjellsbells wrote:
| > queryable RDBMS to store directory-like data, and modernising
| the query language using JSON over a HTTP(S) transport.
|
| Isnt this what identity systems like Azure Entra essentially
| are? I remember that they were always at pains to point out
| that Azure Active Directory was not Active Directory and didnt
| do LDAP.
| newman314 wrote:
| LDAP came from the University of Michigan where it was intended
| to be a "lightweight" alternate of X.500
|
| https://en.wikipedia.org/wiki/Lightweight_Directory_Access_P...
| packetlost wrote:
| > Nowadays I'm think we're better served with a SQL queryable
| RDBMS to store directory-like data
|
| Maybe, but most RDBMS' suck a recursive self-referential
| queries, which mandatory for making a directory system not suck
| to use.
|
| > modernising the query language using JSON over a HTTP(S)
| transport
|
| Eh. Modernizing the query language would be nice, but there's a
| reason _most_ databases don 't make HTTP + JSON the primary
| method by which you interface. Some LDAP systems get absolutely
| _hammered_ , you don't want a bunch of unnecessary overhead and
| connection-building to add to it when you _really_ don 't need
| to. Also expressing queries sanely in JSON would be a pain,
| you'd either just be wrapping a plaintext query in an object or
| doing something incredibly misguided with trying to represent
| the query structure as a bad AST using JSON types.
| ksk23 wrote:
| I like it very much. Fullfills all your SOHO SSO needs!
| generalizations wrote:
| I've often thought that a large fraction of what LDAP does could
| be replaced by a /etc/passwd.d/ directory, with individual files
| for user accounts. Then the accounts could be synced without
| issue or race conditions. And it'd be much simpler to work with
| than that bloated protocol.
| daelon wrote:
| I've been getting into my homelab with proxmox recently, and
| that sounds like exactly what I wish I could do. I tried
| setting up an ldap server but it was way too complicated for my
| use case.
| t312227 wrote:
| hello,
|
| as always ... imho (!)
|
| disclaimer: i'm a big fan of ldap, especially of the FOSS
| openldap implementation and i'm using it since ... ever ... (~ 25
| years)
|
| i think there is one feature which makes openldap stand out and
| which in my experience is _crucial_ for any non-trivial
| directory-implementation someone wants to use:
|
| * easy replication-setups with the possibility to create complex
| (!) topologies.
|
| what i mean with that is maybe best described by the following
| "anecdote":
|
| once upon a time i had the use-case of the migration of some mid-
| sized HPC-clusters - distributed memory - from "good old" NIS to
| LDAP.
|
| ok ... sounds simple: pam-ldap and be done with it!!
|
| sure, but what happens, if the LDAP main server fails!?
|
| no problem, replicate to a second system as a "fail over" eg. HA
| ...
|
| sure, but what happens if the network between the HPC-cluster and
| the LDAP server(s) fails!?
|
| just replicate the directory "read only" to the head-nodes ...
|
| sure, but what happens if the network "in cluster" fails!?
|
| just replicate it to each node ...
|
| now draw out the resulting topology ;))
|
| why? because i wanted to keep the cluster(nodes) utilized even if
| the "worst case" happens.
|
| last but not least: "openldap is a monster" ... sure, but define
| monster ... in my experience once you "groked" ldap and delved
| into the somewhat complex setup of openldap it "just works(tm)"
| ...
|
| but: great project ... :+1: ... and its written in rust ...
| _yawns_ ... ;)
|
| just my 0.02EUR
| NewJazz wrote:
| Seconded. Certainly cool to see people working with important
| protos like LDAP in new ways. For me replication is part of
| security and resiliency design. Read only replicas act as a
| buffer that keeps core infrastructure shielded from malicious
| or poorly configured clients.
| atoav wrote:
| As a relatively young person I think openLDAP is ultimately not
| _that_ hard to use, it just feels very foreign to the modern
| user.
|
| And that has mostly to do with a lack of good documentation and
| syntax/system choices that have been made in times where some
| best practises might not have existed yet.
|
| I must say googling any LDAP issue sucked majorly. But once you
| get the basic hang of how to do X it is somewhat consistent.
| justsomehnguy wrote:
| > sure, but what happens if the network between the HPC-cluster
| and the LDAP server(s) fails!?
|
| Call a network engineer.
|
| For anything else use the multi-master replication, like the
| one built-in in ADDC.
| azophy_2 wrote:
| I'm curious about other's experience with LDAP's supposed
| succesor: SCIM (http://scim.cloud). based on REST, it does sound
| simpler to implement & integrate compared to LDAP. but is it
| actually better compared to LDAP?
| patmorgan23 wrote:
| SCIM + Oath/SAML is pretty solid (SCIM doesn't handle
| authentication just provisioning, de-provisioning, and
| updates).
|
| It flips the script on LDAP as well, instead of the application
| calling in to the directory, the directory/sync service calls
| into the application which has some positive security
| implications.
___________________________________________________________________
(page generated 2024-07-14 23:02 UTC)