0

How one can configure PicketLink (LDAP) to create some basic many to many relationship? Assume: User 0<-->* Role 0<-->* Permission So User can have multiple Role and Role can have multiple permissions.

In PicketLink I can create some Role and add there some users(even custom classes):

member:user1
member:user2

But how can I add some Permission to the same Role or another way to create this many to many realtionship in LDAP\PicketLink? So my Role will looks like this or similar:

member:user1
memberPermission: permission1

I found some information: https://docs.jboss.org/picketlink/2/2.6.0.CR1/reference/html/ch09.html "The LDAP configuration supports the mapping of simple hierarchies (parent/child) of a single type." Is it so that LDAP can't do this?

I also tryed to create some custom membership class for some custom mapping:

    .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")

But at run time I got some error and couldn't add this to my relationshipmanager.

Have anyone seen good example of doing some many to many relationship in LDAP/PicketLink? Or may be have some solution to similar problem?

Stepan Severin
  • 21
  • 6

1 Answers1

0

I'm new to LDAP but I can't find a way to do this either, probably because LDAP is like a tree/hierarchy and not a database. Best I could come up with for a rough many to many (systems<-->users<-->roles) is :

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

Both member and roleOccupant have distinguishedName as their superior so expect a DN as the value. The member attribute is set to a role entry elsewhere (eg cn=ROLE,ou=systemRoles,dc=company) and the roleOccupant is set to a user (eg uid=USERNAME,ou=users,dc=company).

I've put systems at the top since that what I expect to be known for my application but if you wanted to find out the systems for a given user that would be harder. It seems like a many to many relationship is best avoided if at all possible.

BenHT
  • 113
  • 2
  • 7