mirror of
https://github.com/lldap/lldap.git
synced 2026-04-25 00:05:50 +03:00
[GH-ISSUE #301] Allow two way syncing with other Authentication front ends (SCIM/LDAP edits) #113
Labels
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lldap-lldap#113
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @shibco on GitHub (Sep 22, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/301
Thanks for building LLDAP, this is a very necessary implementation of a very overwhelming technology.
Projects like Keycloak (and others) offer many different ways to control new user registration and self service of their accounts. In my research for example, we've learned about system admins using community presence as a tool for self managing semi-open user signup systems, making them public facing but limited or protected from abusive signup through a user's presence in a community. In many cases account creation can happen seamlessly during user sign up.
The flow is like this:
For the user, this strategy is completely invisible. They land on the application, click Sign In via SSO, and are immediately greeted with the onboarding / welcome screen for the application they want to use. If they have an account in LLDAP, the user instead is logged in.
From reading through this project's discussion, I understand that write access or syncing is not on the roadmap for LLDAP right now, but this authentication strategy is growing in popularity, particularly amongst so-called "Dark Forest" public/private communities that require both a degree of openness but still need to protect their infrastructure from abuse. Some examples would include Furality, Lumbung Space, Lurk and Underscore. The simplicity of LLDAP's role as a source of truth for user accounts, combined with this secure but very simple authentication flow would make for a powerful combination for low-complexity account setup and authentication.
An initial implementation of this would simply allow for users to be created inside Keycloak to be synced back to LLDAP. The complete implementation would be to allow Keycloak or similar services to act as the front end for user account management, such as changing their email address or name, in the same place as they can do things like add 2FA.
Finally, as mentioned on the Discord, if this gets built I will post a guide on how to set this up on Underscore.
@poVoq commented on GitHub (Sep 22, 2022):
If you want OIDC (Oauth2) support you could try to use LLDAP with this: https://gitlab.com/yaal/canaille/
@shibco commented on GitHub (Sep 23, 2022):
@poVoq we already have OIDC, the problem is that we'd like new accounts to be created automatically, which is a current limitation to LLDAP.
@nitnelave commented on GitHub (Oct 20, 2022):
Once #346 is submitted, can you give it a try? One thing that I wasn't sure about is how the password is managed. Currently it creates the user without a password and expects KeyCloak to follow that up with a PasswordModifyExtension request. Another possibility is that the password is given in plain text when creating the user (not handled now, but it could be added).
The last possibility (I hope it doesn't come to that) is that KeyCloak sends us the already hashed password. In that case, I'd have to store the hash and use that for logging in, meaning that I'd have to support two possible password schemes, and I'd really like to avoid that.
@shibco commented on GitHub (Nov 2, 2022):
Thanks for your hard work on this! We can definitely do passwords as part of the first sign in (we would use it as a recovery string actually).
It looks like it's merged, and I assume is part of
:latest? If so, I'm getting this error when I try to sync the LDAP database in Keycloak:🚨 [error]: [LDAP] Service Error: while handling incoming messages: while receiving LDAP op: ldapmsg invalidMy settings are the same as the guide, but edit mode is set to
WRITEABLErather thanREAD_ONLY. Any ideas?@ieugen commented on GitHub (Nov 8, 2022):
There is an open standard for user sync between services: SCIM http://www.simplecloud.info/ .
There is a big list of services / implementations on that page.
We use it to sync Azure AD users and groups to AWS IAM Identity Center.
This way we can have users in one environment and be synchronized in the other so we cam use them for access for example.
I would not implement 2 way sync though - it will probably be hard to do right - if possible.
IMO lldap should allow to be a target and a sink for SCIM.
It could be a target and a sink to multiple services.
I guess with this feature it might be possible to have users do 2 way sync ?!
For keycloak I found:
https://github.com/Captain-P-Goldfish/scim-for-keycloak
https://issues.redhat.com/browse/KEYCLOAK-2537
I hope it helps.
@nitnelave commented on GitHub (Aug 3, 2023):
Sorry for the delay on the feature. Is that still something you'd like? I guess this falls under #518 , but I'm surprised we're getting
ldapmsg invalid. Could you provide a pcap so we can have a look?@shibco commented on GitHub (Aug 4, 2023):
Hi @nitnelave, we are still using LLDAP and are very happy with it. This would be a very handy feature!
@nitnelave commented on GitHub (Aug 4, 2023):
@shibacomputer I'm glad you're happy with LLDAP :) Could you get a packet capture of the traffic between keycloak and LLDAP with tcpdump when you get a
ldapmsg invaliderror? I'd like to see what they send.LLDAP already implements creating a new user through the LDAP protocol, so it should work.
@h3mmy commented on GitHub (Aug 22, 2023):
I was unable to reproduce the
ldapmsg invalidscenario. When I switched my keycloak to writeable it generated errors related to the old that's not implemented in lldap yet. Keycloak is still able to successfully import from lldap, but cannot add/modify any lldap user information. I assume that is expected until after #518Scenario
3 users including lldapadmin in lldap
1 user in keycloak realm not in lldap
Keycloak -> set Edit Mode to "WRITEABLE" -> Sync all users
Keycloak logs
lldap logs
@nitnelave commented on GitHub (Aug 22, 2023):
Hmm, that relates to a slightly deeper issue: the query cannot be parsed by the LDAP library we're using. To be fair, I haven't looked into the controls of the LDAP protocol, so I'm not sure what it's supposed to do, but the library just plain drops the message (which is the right thing to do). This needs to be investigated some more, to determine what that control is and whether we want to support it, then adding support in the LDAP library.
@nitnelave commented on GitHub (Aug 22, 2023):
Looking into it, it seems to be ManageDsaIT control, which only comes into play when using referrals (AFAIU references to entries in other, connected LDAP servers), which we don't support. We can check with the LDAP library if it's conceivable to report unsupported controls without failing the parse, so we can ignore it.
@h3mmy commented on GitHub (Aug 23, 2023):
That's good to know. I know the old for the LDAPv3 modify password request is 1.3.6.1.4.1.4203.1.11.1 (https://www.rfc-editor.org/rfc/rfc3062) but is also an extended operation, so may be out of scope for lldap.
I do think this specific issue of having keycloak write back to lldap would be covered by #518 if you are looking to merge them together.
@nitnelave commented on GitHub (Aug 23, 2023):
The modify password extended operation is supported. What's not supported is the use of controls for operations, basically opt in options. That's what's failing here, and it won't be covered by #518 (though 518 is probably also necessary)
@nitnelave commented on GitHub (Sep 14, 2023):
Can you give it another try? We now support that specific control.
@h3mmy commented on GitHub (Sep 15, 2023):
Did the same thing. No changes to the users, 1 user in keycloak not in lldap. In Keycloak: User Federation -> Sync all users
No errors were observed in this scenario. User was not added to lldap (I believe this is expected for now)
Keycloak logs:
lldap logs:
@nitnelave commented on GitHub (Sep 15, 2023):
@h3mmy could you retry with the verbose LLDAP logs? There isn't much to see right there
@h3mmy commented on GitHub (Sep 15, 2023):
Sure!
Again, no users changed, via keycloak "User Federation" -> "Update all users"
@nitnelave commented on GitHub (Sep 16, 2023):
Hmm, I see a perfectly normal session listing the groups and then the users. If there's any problem left, we'll have to find them in the other service. I can imagine that we're not returning a property that they expect, but I wouldn't know what's missing.
@h3mmy commented on GitHub (Sep 17, 2023):
Yes, that is correct. I did not observe any errors. Because I didn't change any users i don't think it would have tried to use the controls involved with LDAP write.
It does seem to be fine with the ManageDsaIT control though.
@nitnelave commented on GitHub (Jan 22, 2024):
I'm closing this issue because I think it was resolved, feel free to re-open if it's not.
@h3mmy commented on GitHub (Jan 23, 2024):
I would like a scope clarification. Based on the closing of this issue, I should be able to create/edit users in LDAP via an external idp such as keycloak. Is that correct?
@nitnelave commented on GitHub (Jan 23, 2024):
Creating users through LDAP is possible, so a basic sync is possible. Editing users is not implemented, though. Is it required for your needs?
@h3mmy commented on GitHub (Jan 23, 2024):
I run keycloakand authentik in my homelab. I want to be able to manage my users in keycloak and have them stay in sync with an LDAP backend. This requires the LDAP backend to be writeable.
As I understand it, in the current state lldap is not capable of this. I want to know which issue to watch since this one is closing.
@lulezi commented on GitHub (Nov 24, 2024):
Hi @nitnelave, I'm using lldap as a backend for authelia for our cycling club's SSO. The user data is synced to lldap from our member management tool using some Go I cobbled together. After implementing the user creation I got to user modification and came to find out that it's not yet supported by lldap. Do you have any plans for this?
@nitnelave commented on GitHub (Nov 24, 2024):
It's on the to-do list, but I don't have time to work on LLDAP these days. If someone wants to implement it, it shouldn't be too hard and I can provide guidance, but I don't expect to work on this in the coming months.
However, for your use case, unless you want to be generic, it sounds like you'd be better served by the GraphQL API, the command line interface (potentially scripted by go), or the bootstrap script (declarative users and groups)
@lulezi commented on GitHub (Nov 25, 2024):
great, I'll try the GraphQL API, thanks!