How to use LDAP Bridging
You can connect to Lightweight Diretory Access Protocol (LDAP) information sources with Kinetic Bridging.
Kinetic Bridging with LDAP
LDAP bridging allows you to connect to external LDAP information stores so you can collect, present, and use that data in Kinetic Request.
Configuring the LDAP Bridge Console
After installing the LDAP Bridge, here's how to configure it to point to your LDAP data source. We'll demonstrate the process by pointing to an open server that's freely available for testing.
- Server: ldap.testathon.net
- Port: 389
- Security Principal: cn=stuart,ou=Users,dc=testathon,dc=net
- Security Credentials: stuart
- Search Base: dc=testathon,dc=net
- Page Size: 50
- Maximum Pages: 20
You can test connectivity to the LDAP server by clicking the Update button at the bottom of the page. If you've set it up correctly, the word initialized will appear next to the Bridge Settings heading.
Identifying Your Sources
Seeing the structure of the source data can help you understand what you're searching for. A tool like Softerra's LDAP Browser can be very helpful for this kind of work. Here's how to configure the Softerra tool for the "testathon" server.
- Host: ldap.testathon.net:389
- Base DN: dc=testathon,dc=net
- Mechanism: Simple
- Principal: cn=stuart,ou=Users,dc=testathon,dc=net
- Password: stuart
When you've connected to the server with the LDAP browser, you can easily see how the data is laid out. For example, here's the "person record" for a guy named Dennis Doorbell.
We've highlighted the attribute "inetOrgPerson" because the objectClass is what the LDAP Bridge uses as the data source structure value. In other words, where the ARS Bridge uses a form name, the LDAP Bridges uses the source value of the objectClass. And in this case, it's "inetOrgPerson".
Configuring the Kinetic Bridge Manager
The Structures Tab
Using either Remedy User or the Mid Tier client, open up the Bridge Manager. On the Structures tab, create a new Model; then add the Model Attributes that we intend to retrieve from the testathon server. In our example, we used "Test People" with the following attributes:
- First Name
- Last Name
- Phone
- User ID
For testing, we want two kinds of Qualifications: one that returns multiple results, and another that returns what we hope will be a single result. We called one "All" and the other "by User ID". The "All" qualification has no parameters, but for "by User ID," we created a Qualification Parameter called "UserID".
The Bridges Tab
Create your Bridge "connection" using the Bridge Path from the web console as the Bridge URL.
The Mappings Tab
Now it's time to "wire up" the elements from the source data store. First, create a Model Mapping entry by clicking the Add button under the Model Mappings table. In our example, we called it "Test People (LDAP)." Connect the model to the correct Bridge connection by selecting the Bridge Name from the drop-down list. Finally, enter the objectClass value in the Structure field. In our case, it's inetOrgPerson.
Next, you'll need to configure each Model Attribute Mapping entry.
- Email:
<%=field["mail"]%> - First Name:
<%=field["givenName"]%> - Last Name:
<%=field["sn"]%> - Phone:
<%=field["telephoneNumber"]%> - User ID:
<%=field["uid"]%>
And finally, you'll need to flesh out the Qualification Mappings.
- All
- Query:
(objectClass=inetOrgPerson) - Result Type: Multiple
- Query:
- by User ID
- Query:
(uid=<%=parameter["UserID"]%>) - Result Type: Single
- Query:
Using LDAP Bridge Data in a Service Item
To test our LDAP Bridge setup, we cloned an existing service item and then added two questions:
- Person (as a Dynamic List)
- Email (as Free Text)
- The goal is for the Person field on the form to appear as a drop-down list of all people found on the testathon server. On selecting a person, we want to retrieve his or her email address and place it in the new Email field.
Configuring the Questions
First, we'll set the Person Question to use bridging.
Next, to set the returned email value into the Email question field, let's create an event. Click the event tab in the Question Dialog. We want the event to fire whenever the Person value changes, so the Event will be change.
Testing the Service Item
Preview the service item. Select an option from the Person menu. This will fill in the email field.
How It Looks in the Bridge Log
I've you've enabled trace logging, you'll see the queries and their return values.
2013-03-12 10:18:34,481 TRACE [http-8085-1 ] - Searching Ldap Records:
2013-03-12 10:18:34,481 TRACE [http-8085-1 ] - Structure: inetOrgPerson
2013-03-12 10:18:34,481 TRACE [http-8085-1 ] - Query: (objectClass=inetOrgPerson)
2013-03-12 10:18:34,481 TRACE [http-8085-1 ] - Fields: uid,uid
2013-03-12 10:18:35,643 DEBUG [http-8085-1 ] - Processing Time: 1162
2013-03-12 10:18:35,654 DEBUG [http-8085-1 ] - Received response:
{"fields":["uid","uid"],"metadata":{"size":"11"},"records":[["alice","alice"],["bob","bob"],["carol","carol"],["claire","claire"],["dennis","dennis"],["ernie","ernie"],["francis","francis"],["john","john"],["noemailmail","noemail"],["stuart","stuart"],["stuart","stuart"]]}
2013-03-12 10:22:47,320 TRACE [http-8085-1 ] - Incoming request for com.kineticdata.bridge.bootstrap.BridgeServlet:
2013-03-12 10:22:47,320 TRACE [http-8085-1 ] - Request URI: /kineticLdapBridge2/api/1.0/retrieve
2013-03-12 10:22:47,320 TRACE [http-8085-1 ] - Servlet Path: /api/1.0
2013-03-12 10:22:47,320 TRACE [http-8085-1 ] - Context Path: /kineticLdapBridge2
2013-03-12 10:22:47,321 DEBUG [http-8085-1 ] - Processing API request.
2013-03-12 10:22:47,321 TRACE [http-8085-1 ] - Retrieving Ldap Records:
2013-03-12 10:22:47,321 TRACE [http-8085-1 ] - Structure: inetOrgPerson
2013-03-12 10:22:47,321 TRACE [http-8085-1 ] - Query: (uid=<%=parameter["UserID"]%>)
2013-03-12 10:22:47,325 TRACE [http-8085-1 ] - Fields: mail
2013-03-12 10:22:48,470 DEBUG [http-8085-1 ] - Processing Time: 1149
2013-03-12 10:22:48,470 DEBUG [http-8085-1 ] - Received response:
{"record":{"mail":"[email protected]"}}
Updated about 3 years ago