Flyspray - The bug killer!

  • Status Planned
  • Percent Complete
    40%
  • Task Type Feature Request
  • Category Backend/Core → Authentication
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 0.9.9.5 devel
  • Due in Version 1.1 devel
  • Due Date Undecided
  • Votes 11
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by simon Whittaker - 21.05.2008
Last edited by Psychokiller1888 - 04.09.2019

FS#1487 - LDAP(Active Directory) Authentication

I have done a very quick bit of work to bring ldap (through active directory) authentication to flyspray for our implementation in the office. I hope it will be of use to others. There is a readme.txt inside talking through the process and the patch to apply. My plan is to expand on this and make it part of the setup process but this will take a bit longer.

This task has the following sub-task
ID Project Summary Priority Severity Assigned To Progress
2209 Flyspray - The bug killer! FS#2209 - TLS support for LDAP Very Low Medium
0%

simon, Great job!!!

Regards
Bronek

is there a port for the current master? seems there has been some refactoring in the code...

just did it, 3 of 4 chunks reject, but if you manually apply it, it works great (i am using 009e01aba031eafacde1ece6d5173a86d63e9fd4)

I manually applied the patch against 0.9.9.7 and created a new patch from the result. The patchcan be found in the tarball below (apply with -p3):
https://aur.archlinux.org/packages/fl/flyspray-ldap/flyspray-ldap.tar.gz

If you use Arch Linux, I created an AUR package that installs patched version of Flyspray with LDAP support.
The PKGBUILD is a bit rough right now and configuration is still in class.flyspray.php, but it works.

https://aur.archlinux.org/packages/flyspray-ldap/

Project Manager

That's definitly a must, will be implemented!

Today i tested the long awaited alpha version 1.0 - and Active Directory authentication are not included, add it please...

Project Manager

As marked in this feature request, it's planned for 2.0. Will maybe be available for 1.1, but not for 1.0 for sure.

Project Manager

Mmh, it seems that patch for 0.9.9.7 only uses php builtin ldap functions, so no need for extra adodb-ldap-inc.php loading here???

Added some code to github for further dev.

Sorry but I do not understand this step "2/ apply the ldapauth.patch to your includes/fclass.flyspray.php and set the variables accordingly"
Pls give more details of this step
Tks

Project Manager

With coming Flyspray 1.0-rc10 LDAP is configurable by flyspray.conf.php and builtin. So the attachments of this task are obsolete.

In the general section of flyspray.conf.php add

auth_method = "ldap"

and add the ldap section.

Example:

[general]
auth_method = "ldap"
 
[ldap]
uri="ldap://example.com:389"
base_dn="ou=users,dc=example,dc=com"
search_user="cn=admin,dc=example,dc=com"
search_pass="password"
filter="uid=%USERNAME%"

There is now also a vagrant example I used for testing connect to slapd on same host: https://github.com/Flyspray/flyspray-vagrant/tree/master/ldap

Things to take care: A mixed userbase installation with

  • LDAP company employees
  • customers with native Flyspray login
  • customers with OAuth2 Flyspray login (Google, Github, ..)

requires some extra hardening settings.

Example

Employee alice is an ldap user account, but who never used Flyspray, so the username alice does not exists in Flyspray installation.

Now a new user alice (e.g. a customer) registers as alice in Flyspray. Flyspray does not know that there is an LDAP alice yet.

Now employee alice is assigned a task by her boss and told to login with her credential stored in ldap. Now she is in the Flyspray account of the customer alice
and the customer still could login as same user alice with credentials stored in Flyspray database.

( Currently there is a fallback: When LDAP login username/password fails it tries the password stored in Flyspray database. )

So until this mixed stuff is cleaned, mixed LDAP+native+Oauth2 should be prevented by

  1. disable OAuth2 if was configured
  2. disable new user registration

For existing user accounts it must make sure foreign (non-company) user account names are no valid internal ldap usernames too. As an LDAP database may change over time (employees come and go) and Flyspray does not control that, some conflict preventing must be done.

I try to add some checks before releasing Flyspray 1.0-rc10 , but I am not an LDAP user and some best practice by people who are familiar with ldap maintainance and managing big user bases in mixed environments could help.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing