slapd-relay - механизм манипуляции данными трансляции для slapd
/usr/local/etc/openldap/slapd.conf
Основное назначение этого механизма манипуляции данными для slapd(8) - отображение контекста именования, определённого в работающей на том же экземпляре slapd(8) базе данных, в виртуальный контекст именования и, при необходимости, выполнение манипуляций с типами атрибутов и объектными классами. Для него требуется наложение slapo-rwm(5).
Этот механизм манипуляции данными, а также упомянутое наложение, являются экспериментальными.
Приведённые ниже директивы slapd.conf применяются к базам данных механизма манипуляции данными трансляции. То есть, они должны следовать за строкой "database relay" и находиться до последующих строк "backend" или "database". Другие относящиеся к базам данных директивы описаны в man-странице slapd.conf(5). Из директив общего назначения для механизма манипуляции данными relay разрешена только директива suffix.
Контекст именования базы данных, представленной в рамках виртуального контекста именования. Наличие этой директивы подразумевает, что одна конкретная база данных, обслуживающая реальный контекст именования, будет представлена в рамках виртуального контекста именования.
База данных relay не перезаписывает автоматически контекст именования запросов и ответов. Для этой цели должно быть явно указано и соответствующим образом настроено наложение slapo-rwm(5). Обычно, если требуется только перезапись контекста именования, достаточно директивы rwm-suffixmassage.
Одним из важных аспектов является то, что правила доступа основываются на работе с идентификационной сущностью, от имени которой выполняется операция. После преобразования из виртуального в реальный контекст именования, для механизма frontend эта операция будет представлена как выполняемая от имени идентификационной сущности в реальном контексте именования. Более того, поскольку механизм back-relay минует операции механизма frontend реальной базы данных путём выполнения операций напрямую через внутренний API оригинального механизма манипуляции данными, правила доступа оригинальной базы данных не применяются, кроме отдельных случаев, например, когда механизм манипуляции данными оригинальной базы данных выполняет контроль доступа сам по себе. Как следствие, в экземплярах базы данных relay должны быть определены собственные правила доступа, совместимые с правилами оригинальной базы данных, и, возможно, с добавлением дополнительных ограничений. Таким образом, в правилах доступа базы данных relay должны указываться идентификационные сущности в реальном контексте именования. Примеры приведены в разделе "ПРИМЕРЫ".
Если не задана директива relay, база данных relay не ссылается на какую-либо конкретную базу данных, но после перезаписи DN запроса обрабатываемой операции осуществляется выбор наиболее подходящей из баз данных.
Это позволяет с помощью тщательно составленных правил перезаписи направлять некоторые запросы к одной базе данных, а некоторые - к другой. Например, аутентификация может отображаться на одну базу данных, а поиск осуществляться в другой, либо можно выбирать различные целевые базы данных в зависимости от DN запроса, и т.д.
Ещё один вариант - отображать одни и те же операции на разные базы данных в зависимости от деталей виртуального контекста именования, например, записи групп получать из одной базы данных, а записи людей - из другой.
Для реализации простого отображения виртуального контекста именования, ссылающегося на единственную базу данных, используйте:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Для реализации простого отображения виртуального контекста именования, при котором определение реального контекста именования осуществляется для каждой операции, используйте:
database relay
suffix "dc=virtual,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Такой вариант может быть полезным, например, для ретрансляции разных баз данных, разделяющих между собой конечную часть контекста именования (ту, которая подвергается перезаписи).
Для реализации старомодных суффикс-псевдонимов (suffixalias), например, отображения виртуального контекста в реальный при запросах, но сохранения реального контекста именования в ответах (без обратного отображения в виртуальный), используйте:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext default
rwm-rewriteRule "dc=virtual,dc=naming,dc=context"
"dc=real,dc=naming,dc=context" ":@"
rwm-rewriteContext searchFilter
rwm-rewriteContext searchEntryDN
rwm-rewriteContext searchAttrDN
rwm-rewriteContext matchedDN
Обратите внимание, что выполняет инициализация наложения slapo-rwm(5), но вместо автоматической перезаписи с помощью директивы rwm-suffixmassage правила перезаписи устанавливаются в явном виде так, чтобы выполнялось отображение всего потока данных из виртуального контекста именования в реальный, но никакого отображения из реального контекста именования в виртуальный не происходило.
Правила доступа:
database bdb
suffix "dc=example,dc=com"
# другие настройки базы данных ...
access to dn.subtree="dc=example,dc=com"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by * read
database relay
suffix "o=Example,c=US"
relay "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=example,dc=com"
# другие настройки базы данных ...
access to dn.subtree="o=Example,c=US"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
by * read
Обратите внимание, что в обоих базах данных идентификационные сущности (в условии <who>) указаны в реальном контексте именования `dc=example,dc=com', а цели (в условии <what>) - в реальном и виртуальном контексте именования, соответственно.
Механизм манипуляции данными relay не соблюдает каких-либо семантик ACL, описанных в man-странице slapd.access(5); контроль доступа полностью делегируется транслируемой базе (базам) данных. Выполняется только проверка доступа на чтение read (=r) для псевдо-атрибута entry и других значений атрибутов записей, возвращаемых операцией Search, поскольку она выполняется механизмом frontend.
конфигурационный файл slapd по умолчанию.
slapd.conf(5), slapd-config(5), slapo-rwm(5), slapd(8).
OpenLDAP 2.4.47 | SLAPD-RELAY(5) | 2018/12/19 |