LDAP is a nightmare, even from a single vendor
February 21, 2007So we have this Oracle Portal, secured by Oracle Single-Sign-On, which interfaces with Oracle Internet Directory, which is an LDAP-compliant directory service. So the entire software stack, except for the operating system (Windows), is a single vendor’s products. And yet, two of us have just spent the better part of a week figuring out how to query and update the Directory from within the Portal.
Manipulating the Directory from its own direct UI is easy, but we don’t want to have our admins muck around in that UI because you get way too much power. We have to find a way to let our admins manipulate a more restricted set of permissions and identities from within Portal. For example, whoever administers a specific set of Reports needs to be able to control access to those reports by adding and removing authorized users.
And that’s the part we’ve been poking around with for the past week. Mostly the DBMS_LDAP and DBMS_LDAP_UTL packages. Yeah, so we’re rolling old-school with PL/SQL API’s instead of Java. You gotta problem with that? These kind of low-level things are much easier in PL/SQL than Java.
Anyway, it’s been amazing to me how poorly documented this API is. And how thin the API is–you’d think, since it’s an all-Oracle solution, they’d have produced nice wrapper packages to abstract stuff like finding all Groups in the Directory, or adding/removing users into those Groups.
But no, you have to write a ton of code to interface and manipulate the LDAP data manually. DBMS_LDAP is a thin layer of spackle on LDAP, you have to understand all the subtleties of stuff like when you search by attribute and when you search by filter. That isn’t entirely obvious, it still isn’t after a week of hacking around.
But at least now we have the basic packages we need built. Stuff to manage the low-level LDAP crap like searching for a user by their human name instead of via some ID. Final step is hooking it into the Portal UI and we’re all set.