LDAP Object Details

The LDAP Object Details section gives an explanation on how LDAP objects and their attributes are mapped to API endpoint operations corresponding to the tenant, group or user levels found back in the Broadworks architecture. This configuration is performed on the and LDAP backend Service Data section of the APIO backends configuration screen.

General Configuration

{
   "Customer_LDAP_Concentrator": {
      "baseDN": "ou=Instance1,dc=acud,dc=intra",
         "tenantMapping": {
            "dn": {
               "read": "{{baseDN}}",
               "modify": "ou={{tenantId}},{{baseDN}}"
            },
            "filter": "(ou={{tenantId}})",
            "custom_filters": {
               "not_in_bwks": {
                  "mode": "and",
                  "criteria": [
                     {
                        "attribute": "tenantId",
                        "operation": "not_exists"
                     }
                  ]
               }
            },
            "id": {
               "key": "ou"
            },
            "objectClasses": [
               "organizationalUnit",
               "top"
            ],
            "mappings": {
               "extObjectId": {
                  "key": "tenantId"
                }
            }
         },
         "groupMapping": {
            "dn": {
               "read": "ou={{tenantId}},{{baseDN}}",
               "modify": "ou={{groupId}},ou={{tenantId}},{{baseDN}}"
            },
            "filter": "(ou={{groupId}})",
            "id": {
               "key": "ou",
            },
            "objectClasses": [
               "organizationalUnit",
               "top"
            ],
            "mappings": {
               "extObjectId": {
                  "key": "groupId"
               }
            }
         },
         "userMapping": {
            "dn": {
               "read": "ou={{groupId}},ou={{tenantId}},{{baseDN}}",
               "modify": "uid={{userId}},ou={{groupId}},ou={{tenantId}},{{baseDN}}"
            },
            "filter": "(uid={{userId}})",
            "id": {
               "key": "uid"
            },
            "objectClasses": [
               "imagicleIntegrationFields",
               "inetOrgPerson",
               "organizationalPerson",
               "person",
               "top",
               "uidObject"
            ],
            "mappings": {
               "extObjectId": {
                  "key": "userId"
               }
            }
         }
      }
   }

This JSON object defines a minimal configuration for an LDAP backend. At the upper level, the identifier of the backend is given. Many LDAP backends may be defined in a single LDAP Server backend so this section may be repated.

An LDAP backend is then made of a baseDN defining the root identity of the LDAP tree (this may be seen as the System level on Broadworks), then three sections called tenantMapping, groupMapping and userMapping defining how the Broadworks levels map to the LDAP tree structure.

Furthermore, each mapping section is made of the following structure (by object, we mean a tenant, a group or a user):

• dn: the reference to uniquely identify the object in the LDAP structure. Note that this reference should be built with placeholders. The following placeholders will be replaced by life values at API triggering time: {{baseDN}} will be replaced by the configured base DN, {{tenant_id}} will be replaced by the tenant ID retrieved from the API call, {{group_id}} will be replaced by the group ID retrieved from the API call, {{user_id}} will be replaced by the user ID retrieved from the API call. Note that those IDs refer to LDAP references, not Broadworks one.

• read: the DN used for read operations

• write: the DN used for create / delete / modify operations

• filter: the filter used to isolate one specific object in the DN

• custom_filters: a collection of pre-defined filters that can be used by the custom_filter= parameter in GET operations for tenants, groups or users. Definition of custom filters works the same way as described in LDAP Filter Details section

• id: the ID of the object in the LDAP tree structure

• key: the real ID key used to map the ID

• objectClasses: an array of LDAP classes used at object’s creation

• mappings: this section helps the mapping of whatever it is called LDAP attribute of the object to a “standardised” name (which may be arbitrary chosen by this configuration). See next section for a complete explanation on how these mappings build the behaviour of the different API endpoints.

Attributes Mapping

Name	Type	Methods				Description
		GET	POST	PUT	DELETE
id	String	A	R	F	F	The identity of the LDAP tenant, group or user. This is most of the time a simple name.
ou	String	A	F	F	F	The complete OU to uniquely identify the tenant, group or user in the LDAP tree structure.

These two attributes are the only ones that will always be present in the tenant, group or user LDAP operations. Other attributes may be added to this list by configuring the mappings section in the Service Data configuration of the LDAP Server backend. This has to be done for tenantMapping, groupMapping and userMapping levels in the Service Data configuration section (see APIO documentation for a full explanation of LDAP Server backend configuration).

One simple mappings example from the LDAP Server backend for the tenantMapping level:

{
   "mappings": {
      "extObjectId": {
         "key": "tenantId",
         "required": true
      },
      "description": {
         "key": "description"
      },
      "destinationIndicator": {
         "key": "udsProxy",
         "readonly": true
      }
      "enableCMS": {
         "key": "enableCMS",
         "readonly": true,
         "type": "boolean"
      }
   }
}

This will add following attributes to the tenant operations:

Name	Type	Methods				Description
		GET	POST	PUT	DELETE
tenantId	String	A	R	O	F	Mapped to the LDAP extObjectId attribute.
description	String	A	O	O	F	Mapped to the LDAP description attribute.
udsProxy	String	A	F	F	F	Mapped to the LDAP destinationIndicator attribute.
enableCMS	Boolean	A	O	O	F	Mapped to the LDAP enableCMS attribute.

Note

When a mapping exists but the attribute is not existing in the LDAP structure for this tenant, group or user, the mapped property is hidden from the result of a GET operation.