Хотите создать отношения "многие ко многим" в PicketLink (LDAP)?

Question

Как можно настроить PicketLink (LDAP) для создания базовых отношений "многие ко многим"? Предположим: Пользователь 0<->* Роль 0<->* Разрешение Таким образом, пользователь может иметь несколько ролей, а роль может иметь несколько разрешений.

В PicketLink я могу создать некоторую роль и добавить туда некоторых пользователей (даже пользовательских классов):

member:user1
member:user2

Но как я могу добавить какое-то Разрешение к той же роли или другой способ создания этого множества в LDAP\PicketLink? Так что моя роль будет выглядеть следующим образом:

member:user1
memberPermission: permission1

Я нашел некоторую информацию: https://docs.jboss.org/picketlink/2/2.6.0.CR1/reference/html/ch09.html"Конфигурация LDAP поддерживает отображение простых иерархий (родитель / потомок) одной тип." Это так, что LDAP не может сделать это?

Я также попытался создать некоторый пользовательский класс членства для некоторого пользовательского сопоставления:

    .mapping(CustomGroup.class)
        .baseDN(CG_DN_SUFFIX)
        .objectClasses(GROUP_OF_NAMES)
        .attribute("name", CN, true)
        .readOnlyAttribute("createdDate", CREATE_TIMESTAMP)
        .parentMembershipAttributeName("member")
        //.parentMembershipAttributeName("usermember")
    .mapping(CustomGroupMembership.class)
        //configure which identity type is the owner of a relationship
        .forMapping(CustomGroup.class)
        .attribute("member", "member")
        .attribute("memberPermission", "memberPermission")

Но во время выполнения я получил какую-то ошибку и не смог добавить ее в свой менеджер отношений.

Кто-нибудь видел хороший пример использования отношений многие ко многим в LDAP/PicketLink? Или может быть есть какое-то решение аналогичной проблемы?

Answer 1

Я новичок в LDAP, но также не могу найти способ сделать это, вероятно, потому что LDAP - это дерево / иерархия, а не база данных. Лучшее, что я мог бы придумать для грубых "многие ко многим" (systems<->users<->role), это:

organizationalUnit ou=systems
  entries : device cn=system name
    entries : custom object with a member and a roleOccupant

И member, и roleOccupant имеют в качестве старшего отличительного имени, поэтому ожидайте DN в качестве значения. Атрибут member установлен на запись роли в другом месте (например, cn=ROLE,ou=systemRoles,dc=company), а roleOccupant установлен на пользователя (например, uid=USERNAME,ou=users,dc=company).

С тех пор я поставил системы на первое место, что, как я ожидаю, будет известно для моего приложения, но если вы захотите узнать системы для данного пользователя, это будет сложнее. Кажется, что лучше избегать отношений между многими, если это вообще возможно.