Я работаю над дизайном структуры LDAP, которая в основном должна содержать пользователей и группы. Должна быть поддержка вложенных групп (поэтому я подумал об использовании groupOfNames объектный класс), а для пользователей я буду использовать inetOrgPerson. Однако есть одно дополнительное условие - есть группы, в которых в настоящее время не будет участников.
Таким образом, мое исследование показывает, что я могу рассмотреть возможность использования groupOfEntries как объектный класс в моем экземпляре openLDAP. Это то же самое, что и groupOfNames за исключением того, что атрибут члена является необязательным (ДОЛЖЕН). Я не могу найти официальную документацию, в которой говорится, как работать с необязательным членством используя стандарт Классы объектов LDAP.
Я нашел черновик для groupOfEntries в IETF с 2008 года, но мне не удалось собрать больше информации.
Есть ли официальное решение, следует ли использовать этот объектный класс?
Присутствует ли он в какой-либо дополнительной схеме, которую можно импортировать в openLDAP?
Мои соображения в основном сводятся к тому, "насколько хорошо поддерживается", "насколько безопасным" и "насколько официальным" считается использование этого класса объектов? Я хотел бы услышать некоторые мнения по этому поводу, также будут оценены любые предложенные альтернативы. Спасибо за ваше время!
В Финдли проект был создан для обеспечения механизма группировки, в котором member атрибут МОЖЕТ (НЕ ДОЛЖЕН), как вы обнаружили. На некоторых серверах есть схема, на других - нет. Схема содержится в черновике. Однако я не думаю, что после драфта велось какой-либо активности.
Некоторые продукты сервера каталогов поставляются с поддержкой groupofEntries но не все. Сервер каталогов UnboundID и, возможно, OpenDS поддерживают groupofEntries в виде схемы, но ничто не мешает администратору предоставить соответствующие элементы схемы.
Что касается того, является ли это хорошей идеей: если она вам нужна, а ваши клиенты LDAP требуют и не могут быть перекодированы для поддержки RFC (в отличие от бездействующего черновика), или если это требуется для модели данных, то администратор должен поддерживать Это. Клиенты, серверы и разработчики моделей данных должны придерживаться стандартов, но там, где чувствуется, что стандарт несовершенен, популярной может стать альтернатива.
Взгляните на organizationRole и groupOfUniqueNames.