LDAP Apache Directory

The purpose of this guide is to provide detailed information regarding the Apache Directory connector. There are a number of things you can learn about this connector here, including information about its configuration and deployment.

info

LDAP Apache Directory connector is not available currently and is coming soon

About LDAP Apache Directory Connector

In IDHub, you can create and onboard LDAP Apache Directory applications using the connector.

Connector Operations

Operation	Supported?
User Management
Create user	Yes
Update user	Yes
Delete user	Yes
Enable user	Yes
Disable user	Yes
Group Management
Create group	Yes
Delete group	Yes
Organizational Unit Management
Create organizational unit	Yes
Delete organizational unit	Yes

Connector Components

The components of the connector include Connector Application, Connector Application Configuration, Connector Service Provider Interface, Splice, and Splice configuration.

These connection components contain precise connectivity and setup information for your target system. The connector takes information from these files to allow you to quickly and efficiently onboard your applications using a single, streamlined UI.

Connector Architecture

The connector's architecture is constructed in accordance with the diagram below: The connector architecture primarily consists of a connector application and a target system component, as seen in the screenshot up above. The native communication with the target system is handled by the target system by leveraging the SPI implementation of the Apache Directory Specific connection. This architecture is implemented because it allows for rapid and straightforward connector deployment as well as precise versioning capabilities.

The connector is configured to run in one of the following modes:

Target Resource reconciliation
- Users are instantly created and changed on IDHub in this situation if you rely on the Apache Directory application as the trusted source. When user records match the reconciliation criteria, the Apache Directory SDK retrieves them and sends them to IDHub. Each user record retrieved from the target system is cross-checked against existing IDHub Users. If there is a match between the target system record and the IDHub User, the User attributes are changed to reflect the changes made to the target system record. If no matches are identified, the target system record is utilized to generate an IDHub User.
Account management
- This entails using IDHub to add, modify, or remove users from the target system.
  - During provisioning, the connector invokes the target system's Apache Directory SDK for provisioning tasks.
  - The target system's SDK accepts provisioning data, does the necessary actions there, and then sends IDHub the result back from the target system. Applications can carry out create, read, update, and delete (CRUD) actions on the target system using the Apache Directory SDK.

note

In developing the connector, we adhere to this fundamental architecture. The IDHub team will handle the connector modification section appropriately based on your unique business requirements if there are any improvements, extra specifications, or variations.

Connector Features

Full Reconciliation and Incremental Reconciliation

Full reconciliation can be performed to bring all existing user data from the target system to IDHub. If the target system has an attribute that stores the timestamp at which an item is created or modified, you can configure your connector for incremental reconciliation once the first full reconciliation operation has been completed.

info

The connector's future release version will incorporate incremental & batched recon, which is not supported by the present version of the connector.

Limited Reconciliation

Records from the target system can be reconciled depending on a defined filter condition. You can define the subset of newly added or updated target system records that must be reconciled in order to restrict or filter the records that are fetched into IDHub during a reconciliation process. You can specify the conditions in which the reconciliation will take place.

Batched Reconciliation

You can break down a reconciliation run into batches by specifying the number of records that must be included in each batch.

Support for Connector Server

By using one or more connector servers, the connector architecture permits your application to communicate with externally deployed bundles. In other words, a connector server enables remote execution of an IDHub connector.

Creating an Application by using the Connector

Pre-requisites

Establish connection parameters to the LDAP server

In this step you create the server instance, establish the connection parameters, and identify the entry point in the LDAP hierarchy.

Start Apache Directory Studio.
In the LDAP Servers view, create an LDAP server:
- Click the New Server button in the view toolbar.
- Select the default Apache DS 2.0.0.
- Click Finish.
- Double-click the server to see its content in the display area. Notice the port number and the available partitions
In the LDAP Servers view, select and start the server. If it does not start on the first try, try again, or delete and recreate the server.
After the server is started, in the Connections view, create a new connection:
- Click the New Connection button in the view toolbar.
- Enter ODM1 as the connection name (the name is not used anywhere else).
- Enter the hostname and and the port number
Click Next. In the next screen, enter uid=admin,ou=system for Bind DN or user, and secret for Bind password. This is the default user required to access the Apache Directory server
Click Check Authentication. Authentication must be successful before moving on. Then click Finish.

Create the first user

In this step, you create an organization unit (ou) in which to place users, and create the first user

In the LDAP Browser view, right-click dc=example,dc=com, and select New > New Entry.
Select Create entry from scratch, and click Next.
Under Available object classes, find organizationalUnit and add it to Selected objects classes
Click Next. Then, for the RDN (relative distinguished name) field, enter ou=users
Click Next and then Finish. The LDAP Browser shows that your domain now has an organizational unit in which to place users
Create the first user, Jim. In the LDAP Browser view, right-click ou=users, and select New > New Entry.
Select Create entry from scratch, and click Next.
Under Available object classes, find inetOrgPerson and add it to Selected object classes. This is a general purpose object class that holds attributes about persons.
Click Next. For RDN, enter uid=Jim
Create the first user, Jim. In the LDAP Browser view, right-click ou=users, and select New > New Entry.
Select Create entry from scratch, and click Next.
Under Available object classes, find inetOrgPerson and add it to Selected object classes. This is a general purpose object class that holds attributes about persons.
Click Next. For RDN, enter uid=Jim

Create the first group

In the LDAP Browser view, right-click dc=example,dc=com, and select New > New Entry.
Select Create entry from scratch, and click Next.
Under Available object classes, find organizationalUnit and add it to Selected objects classes.
Click Next. Then, enter for the RDN field, ou=groups. Click Next and then Finish. The LDAP Browser views shows an organizational unit in which to place groups.
Create the first group, Checkers. In the LDAP Browser view, right-click ou=groups, and select New > New Entry.
Select Create entry from scratch, and click Next.
Under Available object classes, find groupOfNames and add it to Selected object classes
Click Next. For RDN, enter cn=Checkers.
Click Next. In the DN Editor, click Browse and select Jim under ou=users.
Click OK and then Finish. The group Checkers now has a member Jim.

Onboard the Application in IDHub

tip

Click here for the detailed steps for onboarding the application to IDHub

Configuring the Connector

Connectors use connection-related parameters to connect to IDHub with your target system and perform connector operations when creating a connected application. IDHub requires the following connection-related parameters in order to connect to an Apache Directory application.

Parameter	Default value	Description
id	N/A	The LdapServer identifier
transports	N/A	The LdapServer transports
confidentialityRequired	false	Tells the server to accept requests using startTLS or LDAPS
allowAnonymousAccess	true	Tells the server to accept Anynymous requests or not
maxSizeLimit	1000	The maximum number of entries to return
MaxTimeLimit	1000	The maximul time before an operation is aborted (in seconds)
saslHost	N/A	The name of this host, validated during SASL negotiation
saslPrincipal	ldap/ldap.example.com@EXAMPLE.COM	The service principal, used by GSSAPI
saslQop	"auth, "auth-int", "auth-conf"	The quality of protection (QoP), used by DIGEST-MD5 and GSSAPI
saslRealms	N/A	The realms serviced by this SASL host
directoryService	N/A	The reference to the associated DirectoryService
keystoreFile	The JVM keystore	The keystore file to use to store certificates
certificatePassword	N/A	The certificate passord

Attribute Mappings for the Connector

LDAP Schema	User Schema in IDHub	Sync Direction	IsVisible	Example	Type of Attribute
displayName	displayName	Bi-Directional	Visible	John33
firstName	firstName	Target system to IDHub	Visible	John
mail	email	Target system to IDHub	Visible	John@sath.com	Account Name Field
sn	lastName	Target system to IDHub	Visible	Garret
cn	login	Target system to IDHub	Visible	John_g33	Recon Key
telephoneNumber	phoneNumber	Target system to IDHub	Visible	355-5656-6666

tip

Sync Direction of the Attributes depends on whether you regard LDAP Apache Directory as your Trusted Source.
You should only synchronize from IDHub to Apache Directory and not the reverse if Apache Directory is not a trusted system in your case.

Possible Recon Key	Possible Recon Key Values
mail	John@sath.com
userLogin	John33
employeeNumber	John8678

Connector Application Configuration

Connector application is designed such that it works as the wrapper application to the different scim adapters. This majorly consists of the following:

Authentication

Basic Authentication is required
The encrypted values of username and password will be stored in the properties file

Resource Type

These are the two resource types available for the IDHub connector. The "resourceName" attribute value in rest api calls will have one of these values.

Account - user account in the target system - this will include entitlement membership
Entitlement -available entitlements in the target system

Connector Splice Design

Account Schema

The Account Schema configuration of the LDAP connector Splice is as follows:

{
  "id": "urn:sath:params:scim:schemas:ldap:2.0:Account",
  "name": "Account",
  "description": "User Account",
  "schemas": [
    "urn:sath:params:scim:schemas:core:2.0:Schema"
  ],
  "meta": {
    "resourceType": "Schema",
    "location": "/v2/Schemas/Accounts"
  },
  "attributes": [
    {
      "name": "cn",
      "multiValued": false,
      "description": "The UserLogin / id of the user.  REQUIRED.",
      "returned": "always",
      "uniqueness": "global",
      "required": true
    },
    {
      "name": "givenName",
      "type": "string",
      "multiValued": false,
      "description": "The FirstName of the user.  REQUIRED.",
      "returned": "always",
      "required": true
    },
    {
      "name": "sn",
      "type": "string",
      "multiValued": false,
      "description": "The LastName of the user.  REQUIRED.",
      "returned": "always",
      "required": true
    },
    {
      "name": "displayName",
      "type": "string",
      "multiValued": false,
      "description": "The DisplayNameame of the user.  REQUIRED.",
      "returned": "always",
      "required": false
    },
    {
      "name": "telephoneNumber",
      "type": "string",
      "multiValued": false,
      "description": "The phoneNumber of the user.",
      "returned": "always",
      "required": false
    },
    {
      "name": "mail",
      "type": "string",
      "description": "The mail alias for the user.",
      "required": true,
      "returned": "always",
      "multiValued": false
    },
    {
      "name": "entityBaseDN",
      "type": "string",
      "description": "The user base DN",
      "required": false,
      "returned": "always",
      "multiValued": false
    },
    {
      "name": "password",
      "description": "Account password, Required for Creation Only",
      "required": false,
      "returned": "never",
      "multiValued": false
    },
    {
      "name": "entitlements",
      "description": "Assigned entitlement list",
      "multiValued": true,
      "required": true
    }
  ],
  "schemaConfiguration": {
    "id": "cn",
    "objectClass": [
      "top",
      "person",
      "organizationalPerson",
      "inetOrgPerson"
    ],
    "otherDefaultAttributes": {
 
    },
    "relationshipAttribute": "memberOf",
    "namingAttribute": "cn",
    "defaultBaseContainerDN": "ou=People,dc=iamsath,dc=com"
  }
}

Resource Type Schema

{
  "schemas": "urn:sath:params:scim:schemas:core:1.0:Account",
  "matching-attributes": [
    "uid",
    "mail"
  ],
  "attribute-map": {
    "Fname": {
      "attribute": "Fname",
      "type": ""
    },
    "Lname": {
      "attribute": "Lname",
      "type": ""
    },
    "givenName": {
      "attribute": "Fname",
      "type": ""
    },
    "sn": {
      "type": "",
      "query": ".Lname"
    },
    "displayName": {
      "attribute": "displayName"
    },
    "name": {
      "attribute": "displayName"
    },
    "id": {
      "attribute": "userName"
    },
    "userName": {
      "attribute": "userName"
    },
    "email": {
      "attribute": "email",
      "type": "",
      "query": "{mail: .emails[].value}"
    },
    "phone": {
      "attribute": "phone",
      "type": ""
    },
    "title": {
      "attribute": "title",
      "type": ""
    },
    "addresses": {
      "attribute": "addresses",
      "type": ""
    },
    "department": {
      "attribute": "department",
      "type": ""
    },
    "userType": {
      "attribute": "userType",
      "type": ""
    },
    "organization": {
      "attribute": "organization",
      "type": ""
    },
    "employeeNumber": {
      "attribute": "employeeNumber",
      "type": ""
    },
    "manager": {
      "attribute": "manager",
      "type": ""
    }
  },
  "scripts": {
  "insert": ["dn: cn=${this.uid},ou=${this.ou},dc=iamsath,dc=com\nobjectClass: top\n#person\nobjectClass: person\nsn: ${scim.name}\ncn: ${scim.Fname} ${scim.Lname}\ntelephoneNumber: ${scim.phone}\nseeAlsodescription:\n#org person\nobjectClass: organizationalPerson\ntitle: ${scim.title}\nx121Address:\nregisteredAddress:\ndestinationIndicator:\npreferredDeliveryMethod:\ntelexNumber:\nteletexTerminalIdentifier:\ninternationaliSDNNumber:\nfacsimileTelephoneNumber:\nstreet: ${scim.addresses.streetAddress}\npostOfficeBox:\npostalCode: ${scim.addresses.postalCode}\npostalAddress: ${scim.addresses.region}\nphysicalDeliveryOfficeName:\nou: People\nst: ${scim.addresses.region}\nl: ${scim.addresses.locality}\n# inet org person\nobjectClass: inetorgperson\naudio:\nbusinessCategory:\ncarLicense:\ndepartmentNumber: ${scim.department}\ndisplayName: ${scim.displayName}\nemployeeNumber: ${scim.employeeNumber}\nemployeeType: ${scim.userType}\ngivenName: ${scim.givenName}\nhomePhone: ${scim.phone}\nhomePostalAddress: ${scim.addresses.region}\ninitials:\nlabeledURI:\nmail: ${scim.email}\no: ${scim.organization}\npager:\nroomNumber:\nsecretary:\nuid: ${scim.userName}"],
  "update": ["dn: cn=${this.uid},ou=${this.ou},dc=iamsath,dc=com\nobjectClass: top\n#person\nobjectClass: person\nsn: ${scim.name}\ncn: ${scim.Fname} ${scim.Lname}\ntelephoneNumber: ${scim.phone}\nseeAlsodescription:\n#org person\nobjectClass: organizationalPerson\ntitle: ${scim.title}\nx121Address:\nregisteredAddress:\ndestinationIndicator:\npreferredDeliveryMethod:\ntelexNumber:\nteletexTerminalIdentifier:\ninternationaliSDNNumber:\nfacsimileTelephoneNumber:\nstreet: ${scim.addresses.streetAddress}\npostOfficeBox:\npostalCode: ${scim.addresses.postalCode}\npostalAddress: ${scim.addresses.region}\nphysicalDeliveryOfficeName:\nou: People\nst: ${scim.addresses.region}\nl: ${scim.addresses.locality}\n# inet org person\nobjectClass: inetorgperson\naudio:\nbusinessCategory:\ncarLicense:\ndepartmentNumber: ${scim.department}\ndisplayName: ${scim.displayName}\nemployeeNumber: ${scim.employeeNumber}\nemployeeType: ${scim.userType}\ngivenName: ${scim.givenName}\nhomePhone: ${scim.phone}\nhomePostalAddress: ${scim.addresses.region}\ninitials:\nlabeledURI:\nmail: ${scim.email}\no: ${scim.organization}\npager:\nroomNumber:\nsecretary:\nuid: ${scim.userName}"],
    "delete": [],
  "select": [],
  "mappingToExistingToResponse": [
    {
      "id": "cn=${ldif.cn}, ou=${ldif.ou}, dc=iamsath, dc=com",
      "externalId": "${ldif.dn}",
      "userName": "${ldif.uid}",
      "givenName": "${ldif.givenName}",
      "displayName": "${ldif.displayName}",
      "name": "${ldif.displayName}",
      "emails": "${ldif.mail}",
      "userType": "${ldif.employeeType}",
      "title": "${ldif.title}",
      "department": "${ldif.departmentNumber}",
      "organization": "${ldif.o}",
      "phone": "${ldif.telephoneNumber}",
      "employeeNumber": "${ldif.employeeNumber}",
      "manager": "${ldif.manager}",
      "addresses": {
        "region": "${ldif.postalAddress}",
        "locality": "${ldif.l}",
        "postalCode": "${ldif.postalCode}",
        "streetAddress": "${ldif.street}"
      }
    }
 
  ]
},
  "configs": {
    "OBJECT_CLASS_PRESENT": "(objectClass=person)"
  }
}

Entitlement Schema

{
"schemas"``: ``"urn:sath:params:scim:schemas:core:1.0:Account"``,
"meta"``:{
"resourceType"``: ``"User"``,
"created"``:``"2011-08-01T18:29:49.793Z"``,
"lastModified"``:``"2011-08-01T18:29:49.793Z"``,
"location"``:``"https://example.com/v2/Users/2819c223..."``,
"version"``:``"W\/\"f250dd84f0671c3\""
},
"Fname"``:``"Aman"``,
"Lname"``: ``"Singh"``,
"userName"``:``"asingh"``,
"displayName"``:``"Amar Singh"``,
"phone"``: ``"+1 5555551111"``,
"email"``: ``"amansingh@sath.com"``,
"title"``:``"System Engineer"``,
"addresses"``:{
"region"``:``"Kolkata"``,
"locality"``:``"west-bengal"``,
"postalCode"``:``"700064"``,
"countryCode"``:``"IN"``,
"country"``:``"India"``,
"streetAddress"``:``"Street 31"
},
"department"``:``"Research"``,
"userType"``:``"EMP"``,
"organization"``:``"Exelon"``,
"employeeNumber"``:``"132356456"``,
"manager"``:``"Alexa"
}

Deploying the LDAP Apache Directory Connector

tip

The documentation for deploying the connector is coming soon

LDAP Apache Directory

About LDAP Apache Directory Connector​

Connector Operations​

Connector Components​

Connector Architecture​

Connector Features​

Full Reconciliation and Incremental Reconciliation​

Limited Reconciliation​

Batched Reconciliation​

Support for Connector Server​

Creating an Application by using the Connector​

Pre-requisites​

Establish connection parameters to the LDAP server​

Create the first user​

Create the first group​

Onboard the Application in IDHub​

Configuring the Connector​

Attribute Mappings for the Connector​

Connector Application Configuration​

Authentication​

Resource Type​

Connector Splice Design​

Account Schema​

Resource Type Schema​

Entitlement Schema​

Deploying the LDAP Apache Directory Connector​