8.1.5. LDAP groups mapped into Platform

Warning

You are looking at documentation for an older release. Not what you want? See the current release documentation.

Assume you have a populated directory and some groups that should be mapped into eXo Platform.

To be clear about the LDAP "group", it should be the "groupOfNames" objectClass in OpenLDAP or "group" objectClass in MSAD. In OpenLDAP (default core.schema), the groupOfNames must have the member attribute.

Let's see the portal.war!/WEB-INF/conf/organization/picketlink-idm/examples/acme.ldif file. Under the context DN (ou=Roles,o=acme,dc=example,dc=com), there are several groups:

dn: cn=admins,ou=Roles,o=acme,dc=example,dc=com

dn: cn=employees,ou=Roles,o=acme,dc=example,dc=com

The cn=admins group has a member:

dn: cn=admins,ou=Roles,o=acme,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
cn: admins
member: uid=admin,ou=People,o=acme,dc=example,dc=com

Once the group mapping is done, there should be a group like /acme/roles/admin in eXo Platform. The group name is like a translation of the dn, with the suffix (dc=example,dc=com) is eliminated. The admin user should be a member of this group.

From the concepts, there are two things about group mapping:

The parent group (that is, /acme/roles) must be created (in eXo Platform) manually.
In eXo Platform, a membership is expressed like this: manager:/acme/roles/admin in which manager is a membership type that is required to form a membership. Because the membership type is not an LDAP concept, for the creation of membership, you need to provide a default membership type in configuration.

In this tutorial, you will write your own group mapping configuration but you should refer to sample files (in portal.war!/WEB-INF/conf/organization/picketlink-idm/examples - see the files which have "acme" in name).

Notice the configuration involves 2 files: idm-configuration.xml and picketlink-idm-ldap-config.xml.

Create your group type.

In the idm-configuration.xml file, the Platform parent group needs to be matched with your group type and be declared in ignoreMappedMembershipTypeGroupList field:


<component>

    <key>org.exoplatform.services.organization.OrganizationService</key>

    <type>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</type>

    ...

        <field name="groupTypeMappings">

            <map type="java.util.HashMap">

                ..

                <entry>

                    <key><string>/acme/roles/*</string></key>

                    <value><string>acme_roles_type</string></value>

                </entry>

            </map>

        </field>

        ...

        <field name="ignoreMappedMembershipTypeGroupList">

            <collection type="java.util.ArrayList" item-type="java.lang.String">

                <value><string>/acme/roles/*</string></value>

                ...

            </collection>

        </field>

    ...

</component>

As explained above, a default membership type needs to be configured. Some values you can use are member, manager, editor (those are pre-defined types in eXo Platform but can be re-configured or changed via UI).
```
<field name="associationMembershipType">

    <string>member</string>

</field>
```

In picketlink-idm-ldap-config.xml, the group type is declared under the identity store PortalLDAPStore. First, write a few lines for the schema of the group type, you will fill up attributes and options later:


<identity-store>

    <id>PortalLDAPStore</id>

    ...

    <supported-identity-object-types>

        <identity-object-type>

            <name>acme_roles_type</name>

            <relationships>

                <relationship>

                    <relationship-type-ref>JBOSS_IDENTITY_MEMBERSHIP</relationship-type-ref>

                    <identity-object-type-ref>USER</identity-object-type-ref>

                </relationship>

                <relationship>

                    <relationship-type-ref>JBOSS_IDENTITY_MEMBERSHIP</relationship-type-ref>

                    <identity-object-type-ref>acme_roles_type</identity-object-type-ref>

                </relationship>

            </relationships>

            <credentials/>

            <attributes>

                

            </attributes>

            <options>

                

            </options>

        </identity-object-type>

    </supported-identity-object-types>

</identity-store>

The group type needs to be referenced by the PortalRepository repository:


<repository>

    <id>PortalRepository</id>

    ...

    <identity-store-mapping>

        <identity-store-id>PortalLDAPStore</identity-store-id>

        <identity-object-types>

            ...

            <identity-object-type>acme_roles_type</identity-object-type>

            ...

        </identity-object-types>

    </identity-store-mapping>

    ...

</repository>

Add the attributes mapping.

The Platform group "id" is groupName. Its mapping is definitive and is configured by options, not attributes. The other attributes are label and description, both are not mandatory. You can map them to cn and description LDAP attributes.


<identity-object-type>

    <name>acme_roles_type</name>

    ...

    <attributes>

        <attribute>

            <name>label</name>

            <mapping>cn</mapping>

            <type>text</type>

            <isRequired>false</isRequired>

            <isMultivalued>false</isMultivalued>

            <isReadOnly>true</isReadOnly>

        </attribute>

        <attribute>

            <name>description</name>

            <mapping>description</mapping>

            <type>text</type>

            <isRequired>false</isRequired>

            <isMultivalued>false</isMultivalued>

            <isReadOnly>false</isReadOnly>

        </attribute>

    </attributes>

</identity-object-type>

Add options.
- You need to configure the LDAP attribute that matches to group "id" (groupName in Platform). Traditionally, it is cn:
```
<option>

    <name>idAttributeName</name>

    <value>cn</value>

</option>
```
- The ctxDNs (context DNs) accepts multiple values and is the list of the base DNs under which the groups can be found.
```
<option>

    <name>ctxDNs</name>

    <value>ou=Roles,o=acme,dc=example,dc=com</value>

</option>
```
  By default, all the groups under the base will be searched and mapped. You are able to add filter, for example to exclude the "theduke" group:
```
<option>

    <name>entrySearchFilter</name>

    <value>(!(cn=theduke))</value>

</option>
```
- In OpenLDAP or MSAD default schemas, the member attribute is used to list the dn of the members. However, your schema may use another attribute, so it should be configurable (if this option is absent, the group will be mapped without members):
```
<option>

    <name>parentMembershipAttributeName</name>

    <value>member</value>

</option>
```
  Along with it, the isParentMembershipAttributeDN option must be set to true:
```
<option>

    <name>isParentMembershipAttributeDN</name>

    <value>true</value>

</option>
```

As explained above, the parent group ("/acme/roles" in this example) needs to be created manually. You can create it after deploying your custom extension and start the server.

Note

When the LDAP users and groups are mapped into eXo Platform, their data (for example, user profile, personal document, calendar) need to be created as if they were Platform users and groups. See Synchronization for how-to.