LDAP plugin

[DanielAuerX]

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 (?)

[LinkinStars]

@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]

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]

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

[DanielAuerX]

[DanielAuerX]

A manual to test the plugin locally:
LOCAL_TESTING.md

[DanielAuerX]

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]

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:

[LinkinStars]

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.