mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 03:09:39 +03:00
LDAP Group synchronization: memberUid attribute #1948
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @das-kaesebrot on GitHub (Nov 20, 2020).
Describe the feature you'd like
LDAP Group synchronization by the
memberUidattributeDescribe the benefits this feature would bring to BookStack users
Implementing this feature would make it possible to use Bookstack in conjunction with an OpenLDAP server using posixGroups for authorization and Bookstack permissions management.
As of right now, it is only possible to synchronize user groups from an LDAP server to Bookstack using the
memberOfattribute (or another group attribute written to the LDAP user him/herself). Considering that there are quite a few OpenLDAP servers using theposixGroupgroup type which does not supportmemberOfattributes (See here, for example) it would be a great enhancement to implement group synchronization bymemberUid.The main difference between
memberOfandmemberUidis that there is no membership attribute written to the user him/herself, the membership is instead stored only as amemberUidattribute in the posixGroup, containing the uids of all group members.(Please excuse my formatting, this is my first time posting an Issue on GitHub...)
@tiredofit commented on GitHub (Dec 11, 2020):
memberUidhas been deprecated for a long time now with people moving onto RFC2307bismemberOfoverlays. I get the feeling the dev does not want to invest much more time in authentication functionality as its working for the majority of users and wants to focus on improving the overall application.@ssddanbrown commented on GitHub (Jun 15, 2021):
Thanks for the request @das-kaesebrot.
As @tiredofit has pointed out I would not want to dedicate too much additional time or expand out the auth system features unless there's significant benefit in doing so, to ensure the maintenance burden does not grow much greater. Since noone else has previously or since requested
memberUidit appears the demand is very much limited and outside that which I'd deem worthwhile. This is especially so for this case where it is possible to work around the limitation by using amemberOfoverlay on the LDAP system. Therefore I'm going to close this off.