Интеграция Open-XChange 6 с внешним LDAP-каталогом

LDAP
Предыдущая новость была приятной, а эта, пожалуй, станет горькой пилюлей:
Дело в том, что Open-XChange, перешагнув рубеж пятой версии, благополучно растерял всю свою LDAP-ориентированность. В шестой версии в качестве внутреннего хранилища учётных записей используется MySQL, а внешняя аутентификация стала похожа на лабораторную поделку студентов, написанную на коленке за одну пару по принципу «лишь бы сдать».
Чего стоит один только BIND по distinguishedName, формируемому не на основе результатов отбора по значениям атрибутов, а конкатенацие АТРИБУТ=ЛОГИН,baseDN Это значит, что по мнению разработчиков — ВНИМАНИЕ, — все пользователи должны находиться в одном контейнере baseDN на одном уровне. Супер, зачем тогда вообще нужен LDAP, если всё и вся свалено в одну кучу, а список пользователей представляет собой Золотое Руно, которое будучи развёрнутым, в любой крупной организации окажется длиннее тракта Москва-Петербург и предстанет пред очами какой-нибудь секретарши не раньше, чем её разъярнный босс успеет уйти домой, уволив предварительно весь IT-отдел. А ещё модуль LDAP-аутентификации разделяет логин на локальную часть (внутри контекста) и доменную часть (имя контекста), при этом собственно работать с контекстами он не умеет, потому что эта самая контекстная часть не может быть использована в определении baseDN (собственно, там вообще ничего использовано быть не может, поскольку baseDN — это просто статичный набор символов).
Мне удалось обойти эту проблему с использованием оверлея Rewrite из поставки OpenLDAP (вполне стандартным методом, описанным в официальной документации по slapo-rwm), НО, заметьте, такой метод решения — это хакерство, не воспроизводимое на большинстве других серверов каталогов.
Что же делать, что нам предлагают разработчики Open-XChange? А они нам предлагают ни много, ни мало — самим написать на Java соответствующий класс, реализующий модуль LDAP-аутентификации. Нужно отдать должное, для этого разработчики предоставляют исчерпывающую документацию и в целом всё довольно несложно для тех, кто что-то понимает в Java-коде… В чистом виде OpenSource, only code и ничего личного. И всё бы ничего, если бы не было адекватных альтернатив OX, отлично умеющих работать с LDAP и если бы, на минутку вспомним, девелоперы Open-XChange не зарабатывали денег на продаже коммерческой версии, в которой эта проблема также присутствует. Потратив немалые деньги на приобретение Open-XChange, захотите ли вы вкладывать дополнительные средства в его доработку силами штатных или наёмных программистов? Думаю, ответ очевиден…

0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.