Skip to content

LDAP plugin - #294

Draft
DanielAuerX wants to merge 7 commits into
apache:mainfrom
DanielAuerX:ldap_plugin
Draft

LDAP plugin#294
DanielAuerX wants to merge 7 commits into
apache:mainfrom
DanielAuerX:ldap_plugin

Conversation

@DanielAuerX

@DanielAuerX DanielAuerX commented Jun 30, 2025 •
edited
Loading

Copy link
Copy Markdown

Hi, just wanted to check if there is interest in a ldap plugin such as this.

Obviously, some things that are specific to my use case have to be changed before merged, such as the login html and the email dummy solution.

included in this pr:

  • authentication via ldap
  • authentication via ldaps
  • mount and set cert for private ca
  • user attribute can be set to support both openldap vs active directory (uid vs samaccountname)

some ideas for future improvement:

  • better handling of failed logins
  • better solution for the login page (?)

@DanielAuerX
DanielAuerX marked this pull request as draft June 30, 2025 12:24
@LinkinStars

LinkinStars commented Jul 1, 2025

Copy link
Copy Markdown
Member

@DanielAuerX Thank you very much for your contribution. A related issue has been mentioned before. #19 #61
You don't have to worry about the front-end UI. When you finish the feature, we will help to improve it.

@DanielAuerX
DanielAuerX force-pushed the ldap_plugin branch 2 times, most recently from eb5453c to 9812413 Compare July 5, 2025 15:56
@DanielAuerX

DanielAuerX commented Jul 5, 2025 •
edited
Loading

Copy link
Copy Markdown
Author

Hi @LinkinStars, currently i see two issues:

  1. login page: since one is not redirected to separately hosted login page (e.g. the case with the google connector), i am uising the ResponseWriter (wrapped in the GinContext) to provide the user with the login page. I used css specific to my use case, so currently its a plain html login page. Either we could add some default css, let the user upload his/her own css or maybe you have a completely different solution?
  2. since i did not want to send user credentials with a get request, i added an additional endpoint in my implementation added to the answer core. Namely a post endpoint to the PluginAPIRouter calling ConnectorController.ConnectorRedirectDispatcher

@DanielAuerX

DanielAuerX commented Sep 13, 2026

Copy link
Copy Markdown
Author

Hi @LinkinStars, are you still interested in this plugin? If yes, I would continue working on it and finish the PR.

@DanielAuerX

DanielAuerX commented Sep 13, 2026

Copy link
Copy Markdown
Author
answer_ldap_plugin_configurations answer_ldap_plugin_login

@DanielAuerX

DanielAuerX commented Sep 13, 2026

Copy link
Copy Markdown
Author

A manual to test the plugin locally:
LOCAL_TESTING.md

@DanielAuerX DanielAuerX mentioned this pull request Sep 13, 2026
Open
@DanielAuerX

DanielAuerX commented Sep 13, 2026

Copy link
Copy Markdown
Author

Hi @LinkinStars, currently i see two issues:

1. login page: since one is not redirected to separately hosted login page (e.g. the case with the google connector), i am uising the ResponseWriter (wrapped in the GinContext) to provide the user with the login page. I used css specific to my use case, so currently its a plain html login page. Either we could add some default css, let the user upload his/her own css or maybe you have a completely different solution?

2. since i did not want to send user credentials with a get request, i added an additional endpoint  in my implementation added to the answer core. Namely a post endpoint  to the PluginAPIRouter calling ConnectorController.ConnectorRedirectDispatcher

here the related PR in answer core for 2.
apache/answer#1612

@DanielAuerX

DanielAuerX commented Sep 13, 2026

Copy link
Copy Markdown
Author

Hi @LinkinStars, currently i see two issues:

1. login page: since one is not redirected to separately hosted login page (e.g. the case with the google connector), i am uising the ResponseWriter (wrapped in the GinContext) to provide the user with the login page. I used css specific to my use case, so currently its a plain html login page. Either we could add some default css, let the user upload his/her own css or maybe you have a completely different solution?

2. since i did not want to send user credentials with a get request, i added an additional endpoint  in my implementation added to the answer core. Namely a post endpoint  to the PluginAPIRouter calling ConnectorController.ConnectorRedirectDispatcher

Problem described in 1) is addressed in 8c931fdd8a031c88b9b5207d6f7914e308cdb354

This is how the login page would look with branding/favicon and a green primary color:
login_page_with_branding

@LinkinStars

LinkinStars commented Sep 15, 2026

Copy link
Copy Markdown
Member

Hi @DanielAuerX, yes — we are still interested in supporting an LDAP connector. Thank you for picking this up again.

The POST callback change in apache/answer#1612 is the right direction: credentials must not be sent in a GET URL. The custom login page is also acceptable for now; please do not spend more time polishing its visual design yet.

Before we can merge, the two PRs need to complete the existing connector state flow:

  • The LDAP form must preserve and submit the state generated by /connector/login/ldap.
  • This is required for the one-time callback validation and, in particular, for the “bind LDAP account” flow from user settings.
  • Please update the core change so the callback rejects a missing or invalid state, rather than treating it as a normal login.
  • Please add CSRF protection appropriate for a same-site credential form.

Could you also rebase onto the current main branches and update the plugin module path and Answer dependency to match the repository conventions?

For the LDAP connector itself, please add tests for LDAP, LDAPS, StartTLS, private CA, failed authentication, and account binding. We also need a stable, configurable LDAP attribute for ExternalID (for example entryUUID / objectGUID), rather than using a mutable login name.

Once those pieces are updated, we will be happy to review the implementation in detail. Thanks again for the contribution.

@DanielAuerX
feat: init commit
73c82a0
@DanielAuerX
feat: basic implementation
670aeda
@DanielAuerX
feat: working prototype
25c3e13
@DanielAuerX
feat: refacorting and ldaps
d8d4bee 
+ removed logs

+ using login.html

+ implemented ldaps: user can set a cert file for private ca
@DanielAuerX
fix: repair StartTLS handshake and build, add README
6133ea1 
+ set tls.Config.ServerName in dialWithTLS so StartTLS connections
  (non-ldaps:// servers) actually verify. Without it every StartTLS
  attempt failed with "ServerName or InsecureSkipVerify must be
  specified".
+ fix extractUserInfo returning nil for the non-pointer
  plugin.ExternalLoginUserInfo struct, which failed to compile.
+ added missing go.sum and go-ldap/pacman
+ added readme
@DanielAuerX
feat: style login page and pull site branding
7fc3fb3 
+ replace the bare unstyled form with a centered card layout matching common auth-page conventions
+ fetch /answer/api/v1/siteinfo client-side to set the page title, favicon, logo, and accent color from the site's configured branding/theme, falling back to plain defaults if the request fails.
+ keep the RECEIVER_URL_PLACEHOLDER form action and username/password field names unchanged so ConnectorSender/ConnectorReceiver still work.
@DanielAuerX
feat: require and round-trip state, add stable ExternalID
476ceaa 
+ ConnectorSender now reads state via ctx.Request.URL.Query() instead of ctx.Query(), which returns a stale cached value here since core injects state into the raw query after already having called ctx.Query() once. appends it to the receiver url so it survives the login forms post.
+ implemented ConnectorRequireState() to opt into cores strict state validation (cf pr apache/answer#1612). missing or invalid state is now rejected instead of treated as a normal login.
+ ExternalID now comes from a configurable, stable attribute (default entryUUID; objectGUID supported for Active Directory, including proper binary/mixed-endian decoding) instead of the mutable uid or sAMAccountName.
+ added tests (mocked dependencies)
+ dialWithTLS now returns the ldap.Client interface instead of the concrete *ldap.Conn enabling a mock ldap client in tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@DanielAuerX @LinkinStars