Skip to content

LDAP plugin - #294

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

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

Conversation

@DanielAuerX

@DanielAuerX DanielAuerX commented Jun 30, 2025

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

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

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

+ removed logs

+ using login.html

+ implemented ldaps: user can set a cert file for private ca
+ 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

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

Copy link
Copy Markdown
Author
answer_ldap_plugin_configurations answer_ldap_plugin_login

@DanielAuerX

Copy link
Copy Markdown
Author

A manual to test the plugin locally:
LOCAL_TESTING.md

@DanielAuerX

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

+ 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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants