starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00

[GH-ISSUE #352] Support header sso (Forward Auth) #133

New issue

Open

opened 2026-02-27 08:15:26 +03:00 by kerem · 14 comments

kerem commented

2026-02-27 08:15:26 +03:00

Owner

Originally created by @RandomExplosion on GitHub (Oct 25, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/352

Since one common use case for lldap is as a ldap server for a separate authentication server such as authelia it would be good if the web ui was compatible with login from those providers e.g. through trusted header sso

Currently if one wants to put lldap behind 2fa you can still use forward auth with a reverse proxy to block access to the dashboard if you haven't signed in with 2fa but you still need to sign-in again with your password after that.

Basically you can either have username+password or 2x username and password + 2fa
This works fine but does feel a bit clunky.

As I understand it it shouldn't be too difficult to implement either since it takes the place of the current login screen, either way I haven't read through all of lldap's source to know for sure.

Originally created by @RandomExplosion on GitHub (Oct 25, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/352 Since one common use case for lldap is as a ldap server for a separate authentication server such as authelia it would be good if the web ui was compatible with login from those providers e.g. [through trusted header sso](https://www.authelia.com/integration/trusted-header-sso/introduction/) Currently if one wants to put lldap behind 2fa you can still use forward auth with a reverse proxy to block access to the dashboard if you haven't signed in with 2fa but you still need to sign-in again with your password after that. Basically you can either have username+password or 2x username and password + 2fa This works fine but does feel a bit clunky. As I understand it it shouldn't be *too* difficult to implement either since it takes the place of the current login screen, either way I haven't read through all of lldap's source to know for sure.

kerem added the

enhancement

good first issue

backend

labels

2026-02-27 08:15:26 +03:00

kerem commented

2026-02-27 08:15:26 +03:00

Author

Owner

@dvv commented on GitHub (Feb 2, 2024):

@nitnelave
I wonder if we could switch native auth off completely with some config option.
Then authenticating to lldap via authelia (using lldap per se) would be similar to securing vanilla whoami example.

@dvv commented on GitHub (Feb 2, 2024): @nitnelave I wonder if we could switch native auth off completely with some config option. Then authenticating to lldap via authelia (using lldap per se) would be similar to securing vanilla whoami example.

kerem commented

2026-02-27 08:15:26 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 2, 2024):

@dvv How would you get the current user? The proposed way (that I approve) is through trusted headers, but do you have another proposal?

@nitnelave commented on GitHub (Feb 2, 2024): @dvv How would you get the current user? The proposed way (that I approve) is through trusted headers, but do you have another proposal?

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@dvv commented on GitHub (Feb 2, 2024):

Exactly via trusted headers. I think if we remove native login (and probably burden of supporting it) and honor Remote-User: as the current legal user.

@dvv commented on GitHub (Feb 2, 2024): Exactly via trusted headers. I think if we remove native login (and probably burden of supporting it) and honor `Remote-User:` as the current legal user.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@dvv commented on GitHub (Feb 2, 2024):

user_id cookie -> remote-user header
is_admin cookie -> "lldap_admin" in (remote-groups header).split(",")

@dvv commented on GitHub (Feb 2, 2024): `user_id` cookie -> `remote-user` header `is_admin` cookie -> "lldap_admin" in (`remote-groups` header).split(",")

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 2, 2024):

The backend changes are going to be straightforward (just parse the header if it's there), it's the front-end changes that are going to be a bit more challenging, I think: When the frontend loads, it doesn't know which user is logged in. It would have to do a request to the server to check "am I already logged in?" since it can't rely on a cookie.

@nitnelave commented on GitHub (Feb 2, 2024): The backend changes are going to be straightforward (just parse the header if it's there), it's the front-end changes that are going to be a bit more challenging, I think: When the frontend loads, it doesn't know which user is logged in. It would have to do a request to the server to check "am I already logged in?" since it can't rely on a cookie.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@dvv commented on GitHub (Feb 2, 2024):

Well, I believe non-http-only cookies should go away.
Probably there should be some "profile" API (RPC?) method that returns user info.
I didn't dive in client-side of lldap.

@dvv commented on GitHub (Feb 2, 2024): Well, I believe non-http-only cookies should go away. Probably there should be some "profile" API (RPC?) method that returns user info. I didn't dive in client-side of lldap.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 5, 2024):

The only non-http-only cookies right now are storing who's logged in and whether they're admin, but they don't store any credentials (it's to help the frontend). There's a small chance they get out of sync with the actual logged in state (if the session was somehow invalidated from the backend), but so far it's worked out pretty well.

Another way to do it would be indeed to have a "whoami" endpoint that returns the currently logged in user, or none.

@nitnelave commented on GitHub (Feb 5, 2024): The only non-http-only cookies right now are storing who's logged in and whether they're admin, but they don't store any credentials (it's to help the frontend). There's a small chance they get out of sync with the actual logged in state (if the session was somehow invalidated from the backend), but so far it's worked out pretty well. Another way to do it would be indeed to have a "whoami" endpoint that returns the currently logged in user, or none.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@fiinnnn commented on GitHub (Jun 20, 2024):

Is anyone working on this currently? I'm happy to take a shot at implementing it if I have some time.

@fiinnnn commented on GitHub (Jun 20, 2024): Is anyone working on this currently? I'm happy to take a shot at implementing it if I have some time.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@nitnelave commented on GitHub (Jun 20, 2024):

No one's working on it at the moment, it's all yours!

@nitnelave commented on GitHub (Jun 20, 2024): No one's working on it at the moment, it's all yours!

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@tecosaur commented on GitHub (Oct 26, 2024):

@fiinnnn did you take this for a spin? It would be quite cool to have this functionality 🙂

@tecosaur commented on GitHub (Oct 26, 2024): @fiinnnn did you take this for a spin? It would be quite cool to have this functionality :slightly_smiling_face:

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@fiinnnn commented on GitHub (Nov 6, 2024):

@tecosaur unfortunately I haven't been able to find the time to look at this so far, if anyone else would like to try definitely go for it

@fiinnnn commented on GitHub (Nov 6, 2024): @tecosaur unfortunately I haven't been able to find the time to look at this so far, if anyone else would like to try definitely go for it

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@tecosaur commented on GitHub (Nov 6, 2024):

Ah well, that's a bit of a pity but understandable. Thanks for the update!

@tecosaur commented on GitHub (Nov 6, 2024): Ah well, that's a bit of a pity but understandable. Thanks for the update!

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 31, 2025):

Note that propagation of settings to the frontend (#514 ) is done, so this should be easier.

@nitnelave commented on GitHub (Mar 31, 2025): Note that propagation of settings to the frontend (#514 ) is done, so this should be easier.

kerem commented

2026-02-27 08:15:27 +03:00

Author

Owner

@Kumpelinus commented on GitHub (Sep 2, 2025):

FYI: I started working on this Issue

@Kumpelinus commented on GitHub (Sep 2, 2025): FYI: I started working on this Issue

kerem referenced this issue

2026-02-27 08:17:59 +03:00

[PR #133] [MERGED] build(deps): bump codecov/codecov-action from 2.1.0 to 3 #561