View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006758 | mantisbt | ldap | public | 2006-02-27 08:51 | 2019-12-03 06:12 |
Reporter | ape | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Product Version | 0.19.2 | ||||
Summary | 0006758: Access level for users authenticated via LDAP determined by LDAP group membership | ||||
Description | 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. | ||||
Tags | patch | ||||
Attached Files | mantis.schema (449 bytes)
# mantis.schema # This schema is for experimental use only. # All the OIDs are not registered. attributetype ( 1.3.6.1.4.1.999999.1.1 NAME 'mantisAccessLevel' DESC 'Mantis Access Level' EQUALITY caseExactMatch ORDERING caseExactOrderingMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.999999.2.1 NAME 'mantisUser' DESC 'Mantis User' SUP top AUXILIARY MAY ( mantisAccessLevel ) ) | ||||
related to | 0022745 | new | Grant Access in VIEW mode (Read Only) 'skipping' user threshold |
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. |
|
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. |
|
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. |
|
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: 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:
EDIT (dregad) - update GitHub link to http, added markdown formatting |
|
Setting to acknowledge, as no feedback is expected here. |
|