В $ company в настоящее время есть установка, основанная на OpenLDAP с некоторой доморощенной иерархией ^ Whomemutated, плюс некоторые другие данные, хранящиеся в MySQL.
Сервер OpenLDAP содержит такие данные, как внутренние пользователи, контакты клиентов (которые могут иметь доступ к части наших внутренних инструментов, поэтому у некоторых есть информация о пользователях и паролях), фрилансеров, с которыми мы работаем, и адресную книгу. База данных MySQL содержит некоторые дублированные данные от тех же пользователей и некоторую дополнительную информацию, такую как данные о компании клиентов, проектах, которые зависят от компании и, соответственно, от клиента и т. Д.
Мой идеальный план - объединить все в один источник правды.
Интересными для нас частями FreeIPA являются:
Как указано в документации, FreeIPA имеет узкую направленность, являясь IdM, а не общим хранилищем LDAP, но это означает, что если вы хотите расширить информацию о своих отношениях (например: для этого проекта у нас есть эти внутренние пользователи, а те клиенты), вам необходимо иметь некоторое дублирование в другом инструменте (имя пользователя / идентификатор пользователя, группы в FreeIPA для авторизации, соответствующие проекты или компания в дополнительном хранилище данных). Это означает возможное некогерентное состояние между данными в обоих хранилищах, необходимость какой-то синхронизации и т. Д.
Поэтому мне интересно, будет ли распространение FreeIPA, например, для хранения информации о компаниях или проектах такой плохой идеей, и если да, то почему?
Это неплохая идея, однако нужно хорошо спланировать. Мастера FreeIPA реплицируют данные между ними, поэтому любые расширения схемы LDAP лучше поддерживать с помощью инструментов упаковки, чтобы они существовали во всех системах. То же самое относится и к плагинам фреймворка.
Вплоть до FreeIPA 4.4.1 существовала проблема с расширениями схемы, предоставляемыми извне - они не были включены в фазу установки, поэтому вы не могли установить свои расширения с самого начала из-за отсутствия объектного класса / атрибутов в точке обновления код выполняет генерацию ACI, специфичных для вашего плагина, вы можете добавить их только позже. См. Ветку на https://www.redhat.com/archives/freeipa-devel/2016-August/msg00083.html Больше подробностей.
В FreeIPA 4.4.1 я исправил эту проблему (результат обсуждения выше), и теперь вы можете иметь полностью отдельные расширения - см. Пример в моем плагине интеграции FleetCommander по адресу https://github.com/abbra/freeipa-desktop-profile/. В настоящее время я работаю над руководством по расширению для FreeIPA 4.4.1 или новее, чтобы заменить мое старое руководство (https://abbra.fedorapeople.org/guide.html), который более или менее устарел и не затрагивает вопросы обслуживания / распространения, а также дизайн элементов управления доступом.
Пока вы поддерживаете свои дополнения в автономной установке для FreeIPA 4.4.1 или более поздней версии, все будет в порядке.