View Issue Details

IDProjectCategoryView StatusLast Update
0006758mantisbtldappublic2019-12-03 06:12
Reporterape Assigned To 
Status acknowledgedResolutionopen 
Product Version0.19.2 
Summary0006758: Access level for users authenticated via LDAP determined by LDAP group membership

For installations of Mantis with large LDAP authenticated user bases, it might be convenient for a user's access level to be (optionally) determined by membership of an (specified) LDAP group.



related to 0022745 new Grant Access in VIEW mode (Read Only) 'skipping' user threshold 




2006-02-27 09:03

reporter   ~0012236

This might have the added benefit of alowing more harmonisation between, and easier centralised management of, Mantis and other development systems (source code control systems for example). Certain groups could have certain levels of access in Mantis and the SCC system etc.



2009-07-05 20:52

manager   ~0022401

That makes sense. However, the question is whether this will affect only the global access level, or will there be such relationship per project. In other words, how would you like to see private projects access rights managed in your environment.



2010-11-22 01:01


mantis.schema (449 bytes)   
# mantis.schema
# This schema is for experimental use only.
# All the OIDs are not registered.

attributetype (
	NAME 'mantisAccessLevel'
	DESC 'Mantis Access Level'
	EQUALITY caseExactMatch
	ORDERING caseExactOrderingMatch
	SUBSTR caseExactSubstringsMatch

objectclass (
	NAME 'mantisUser'
	DESC 'Mantis User'
	SUP top
	MAY (
		mantisAccessLevel )
mantis.schema (449 bytes)   


2010-11-22 01:01

reporter   ~0027441

Last edited: 2010-11-25 01:21

I've some WIP code for reading access levels from a user's LDAP entry. The access levels are read from an attribute (mantisAccessLevel by default). It's possible to store both global access level and per-project access levels by adding multiple values to the attribute.

I've also attached a LDAP schema of what I used for testing. Note that the OIDs used in the schema have NOT been registered, and are for experimental use only.

The access levels are read from LDAP during authentication, and are saved to the database. Maybe we should also disable modifying access levels from within the web front end?

Any feedback is appreciated.



2010-11-25 01:20

reporter   ~0027484

Last edited: 2019-12-03 06:11

I've fixed a few issues from the commit before, and also added code for pulling access levels from LDAP groups. I've tried out the changes in my own test environment, and the code is behaving as expected.

The end result is the following:
When we authenticate a user, we'll search for access levels from the user and all of the user's groups. Then, we resolve any overlaps by picking the maximum access level.

One remaining question is whether we should block users from changing access levels from the web UI, because we don't have any functionality for updating LDAP right now, just like the realname and email.

Again, any feedback is appreciated.

The following changes since commit 6ffc2de1d5816f49b1cdf002161144b28f2dc6e5:

Update jQuery to 1.4.4, jQuery-UI to 1.8.6 and fix JavaScript MIME types (2010-11-20 10:44:00 +1100)

are available in the git repository at:

Andrew Wong (9):
      Added global config variables for reading access levels from LDAP.
      Read access levels from user's LDAP entry.
      Refactored ldap_get_field_from_username
      Added global config variables for LDAP access levels for groups.
      Fixed an issue in ldap_get_field_from_username when field is "dn"
      Added functions to search for a user's LDAP groups
      Refactored ldap_get_field_from_username
      Use lower case to index the retrieved attributes.
      Read access levels from user's LDAP group

 config_defaults_inc.php |   38 ++++++
 core/config_api.php     |    5 +
 core/ldap_api.php       |  327 ++++++++++++++++++++++++++++++++++++++++++++---
 3 files changed, 349 insertions(+), 21 deletions(-)

EDIT (dregad) - update GitHub link to http, added markdown formatting



2019-12-03 06:12

developer   ~0063168

Setting to acknowledge, as no feedback is expected here.