Trey Drake

My blog has moved to http://treydrake.wordpress.com.

I recently had the need to wire up SugarCRM (an open source customer relationship management app) to OpenDS for centralizing authentication and user provisioning.

The LDAP configuration screen can be found in "admin->system settings". The screenshot below ought to tell the rest of the story though there are a couple gotchas worth noting.

• By default the php LDAP module is not loaded. Install it and load it; e.g., "apt-get install php5-ldap"
• The bind attribute is the entry "dn" versus the suggested "uid".
• The login attribute is the entry "uid" versus the suggested "dn".
• If the "auto create users" checkbox is checked on a successful LDAP bind the user will be created within Sugar. This feature works nicely except that givenname isn't pushed to Sugar, hence, you'll need to manually set the user's last name via Sugar admin screens. I'll file a bug...

Kudos to the SugarCRM team! They set the bar for speed and ease of installing a large, OSS, business application.

Need an intro to OpenDS? Checkout the OpenDS related talks and collateral below.

---

• Intro to OpenDS given at Jazoon '07 by Ludo
• Opends and Web 2.0 podcast featuring the talking heads Don, Brandon, and I
• All things OpenDS given at Capital Area Central Texas UNIX Society by Neil and associated podcast.
• Cool stuff with OpenDS @ Glassfishdays '07 given by Ludo
• Intro to OpenDS slides and related talk given at JavaONE by Don and I

Authentication, Authorization and Accounting, or "triple A", are key requirements for enterprise applications and if Web 2.0 apps are to succeed behind the firewall they too must integrate within the hairball that is the enterprise. The Atom syndication server backed by the OpenDS LDAP server cleanly address the issues and here's how:

---

Authentication: Assertion that the user is who they claim they are; e.g., via username/password

The Atom publishing protocol specification recommends that servers implement a mechanism to ensure agents performing write operations are authenticated. Authentication is handled as follows:

• The user agent is prompted for credentials when an agent performs a POST, PUT, DELETE, and in some cases, a GET request
• In the typical case, a username and password or posted using HTTP BASIC
• The username and password are used to perform an LDAP bind that asserts that the user is present in the directory server and the provided password matches
• On success the principal is stored in the Atom server and a client token is sent in response for future client interactions with the server. Nothing new here.

Authorization: What resources can the authenticated user access and what can they do with them.

The server leverages the underlying servlet container for coarse grained access control and the directory for fine grained control. All atompub operations are protected using container access control that, in the end, simply requires that the user belong to an administratively defined LDAP group; e.g., "atompubwriters". That is, the container simply checks that the context's principal is a member of the appropriate LDAP group.

Fine grain access control is a bit more interesting. In most enterprise applications access controls must be implemented at least twice; 1) the user interface (API or GUI); e.g., locking down fields, screens, modules, etc. and 2) in the database (field, table, etc). Obviously, this is difficult to maintain and when database connection pooling is thrown in the mix correlating the "real" user and the database connection is no longer feasible since the "real" user is lost.

OpenDS solves the connection pooling identity problem with the "proxy authorization control" and fine grain access control with access control instructions (ACIs). The proxy auth control enables the developer to create a connection pool with a common user, say "atomproxy", with just enough privileges to connect to the directory. When a connection is taken from the pool the proxy auth control containing the principal name is attached to the connection thus propagating the real user to the directory. The directory server, recognizing that the proxy auth control is present, uses the proxy principal versus the connection principal to determine access rights. Hence, you get the best of both worlds - connection pooling performance and preservation of end user identity.

For the most part, ACI's are used to narrow or widen user access to some part of the directory information tree. In the case of the Atom syndication server ACI's are added allowing end users write access beneath their LDAP entry enabling them to add blog entries, media resources (podcasts, pictures), etc. Other ACIs are used to filter content available to anonymous users (unauthenticated searching of the Atom server). By using ACI's versus application specific access control a system adminstrator can reliably set user access permissions in a single place throughout the enterprise - the directory.

Accounting/Auditing: Record of user/resource activity; e.g., who changed what when

Accounting comes free! Out-of-the-box OpenDS provides both access and audit logging. The former captures who and what was modified and the latter the contents of the modification (the specific data changes). Further, OpenDS logging/auditing is extensible, hence custom auditing loggers can be written for domain/application specific purposes.

The latest Identity Management Buzz podcast features Brandon Whichard, Don Bowen, and myself discussing Atom, the Atom Publishing Protocol, OpenDS, and how these technologies intersect. Give it a listen. IMO, we cover the highlights without stretching your noodle.

Congrats on the acquisition Scott! When you need a house sitter for your Caribbean villa you just let me know. I hope that SecureTrust/AmbironTrustWave will continue issuing free certs to open source projects.

The OpenDS Atom server is now compliant with the latest Atompub (draft 15) specification and passes all APE tests to include: adding, updating, deleting atom entries and associated media resources. Next up, a bit more hardening and user documentation.

"Tree", as in a directory information tree. Its been slightly over a year since Don and I had a gee whiz moment to front end the directory server with Atom and the Atom Publishing Protocol (APP). A year ago might have been a bit too early for a directory based APP server, though its clearly the right time now. Why?

• Finally, there's a directory server that is lightweight, very fast (read AND write), and developer friendly - OpenDS
• The APP spec appears to be close to completion
• Facilities for search and user authorization are noticeably absent from the APP spec (that's a good thing)
• DSML (LDAP over XML) is deader than a doornail
• Think "syndicated databases"; i.e., databases queried, edited and generally mangled via feeds. I know I'm not the only one thinking about it (checkout Google GBase and Yahoo Pipes).

---

Atom, APP, and OpenDS

• Atom is a simple, extensible specification that describes lists of related information. In its simplest form it is no more than a blog feed.
• APP is a web-based protocol for publishing, editing and retrieving web resources; e.g., Atom documents, xhtml, images, podcast episodes, et al. APP relies on tried and true HTTP and ReST interfaces gaining it a distinct advantage over previous attempts. That is, a widely deployed infrastructure, simple to grok, and relatively simple server and client side implementations.
• OpenDS is an open source, 100% Java directory service

---

Why is an OpenDS based Atom server interesting?

• I have yet to see an Atom/APP implementation application that is identity aware. That is, a server that has intrinsic user knowledge with regards to roles, authorization, authentication mechanisms and user relationships
• Most certainly not file based. Resources posted and fetched are stored in the directory thus enabling synchronization, access control, search, etc.
• Powerful, ReST search based on LDAP Urls
• Built on a scalable architecture. Back-ended by OpenDS, front-ended by Glassfish application server, and written atop Java

---

What can you do with it?

• "Web 2.0" enable your directory. Atom is easily parsed within a web browser and for that matter any other HTTP agent. Therefore, access to the info rich directory is more accessible to external applications and more easily programmed by the neophyte LDAP developer.
• Centrally secure, replicate, and backup Atom documents;e.g., blogs in the directory
• Re-use existing infrastructure and expertise (directory server) to store next gen web content, again, in a secure, scalable fashion
• Monitor the directory through feeds. A simple search on the OpenDS monitor (/atom/search?q=cn=monitor??sub?) dumps a feed of all significant directory statistics
• ...

---

Where can you get it (and contribute to it!)?

Right here, in the first OpenDS sub-project @ http://atom.dev.java.net

How do you demo a directory server? Build cool apps around it. To that end, we've built an Atom/APP server, a lightweight OpenID server, a blogging and "twitter" like app - all powered by OpenDS. Drop by our booth (Glassfish alley at CommunityONE and .org section of the pavilion during JavaONE). Ludo and I will introduce OpenDS and show off the demos in two talks; today at CommunityONE at 5PM and Wednesday at 1:30 in the CommunityCorner.

Our OpenID implementation is getting some press here, here and here. If you happen to be wandering around CommunityONE - we're here (Glassfish alley)! Come with your questions and checkout the demo.

I've been tinkering with public domain OpenIDs for the past few months and found the OpenID service, as it is described, to be useful indeed. I say "as described" since it is clearly not the end all be all Internet authentication service, however, it is interesting and worth exploring further. To that end, I've developed a light-weight, demo quality, OpenID provider. It's easily deployable atop any Java EE container and backed by the OpenDS directory server. Note: Credit goes to Paul Bryan (an OpenSSO contributor) for the initial OpenID protocol handler.

Why develop yet another OpenID provider? Unfortunately, I could not find a maintained, easily deployable, Java EE based provider that actually worked. In addition, as a directory guy, I believe people and identity centric data belong in the directory and not spread amongst n different databases. I'm currently at the O'Reilly Web 2.0 Expo and have been informally polling attendees on general identity management topics; e.g., where are your users stored?, what authentication protocols do you support?, and the like. Brandon, I was wrong - you are right, new applications are still emerging with their own, siloed "user tables" to stuff people and their passwords. Evidently, there is still much education to be done around directory. I trust that this proof-of-concept will assist in showing others the light on how simple it is to support the newest of the new protocols. Give it a try.

---

I'm running the demo atop Ubuntu, Java 6, Glassfish V2, and the latest OpenDS download. Ensure you obtain a build dated 4/21/2007 or later.

1. Install OpenDS
2. Drop in the OpenID schema file. In the case of OpenDS simply drop this file in $opends_home/config and restart OpenDS.
3. Download the OpenID application (WAR) and deploy to your application server. Please note the fine print below.
4. To get started register a new user by "claiming in ID" via the bundled user interface http://localhost:8080/opendsidp/. Copy the generated claim URL; e.g., http://yourhost/opendsidp/claims/username and go use it. For starters try using your claim at http://jyte.com.

The fine print:
Since this is demoware, I made many assumptions about the environment. Most of these assumptions are configurable though a few currently are not. Also, I've left a few features out. In particular, I've left manually accepting/rejecting trust roots for another day.

Please note the following: It is assumed the directory server is on the localhost, listening on port 1389, and may be read by the user cn="directory manager" with the password "password". The base DN is "dc=example,dc=com" and the people base DN is "ou=people,dc=example,dc=com". Additionally, it is required that all OpenID users must belong to the group "openidusers" and that group is located in ou=groups,dc=example,dc=com. The OpenID configuration and authentication tokens (user cookies) are stored in ou=openid, dc=example,dc=com. You do not need to create the groups or openid configuration buckets, they will be created on startup. If your ldap host, port, query user, based dn, or base people dn are different you are free to change the default values by editing the web.xml file located in the WEB-INF directory. The attributes that need changing should be obvious. Confused? Don't be, if you install OpenDS out-of-the-box and accept the default installation configuration you'll be good to go. Good luck!

For kicks I configured my Mac's built-in address book to yank people from OpenDS. It works like a charm.

---

To give it a try:

1. Install OpenDS. Note: If you're just kicking the tires import sample people by selecting the "import automatically-generated sample data" radio button.

2. Add OpenDS to your Address Book. Open the preferences panel in the Address Book application and click the LDAP button. Configure connection parameters as shown below. Done!

Search the address book:

Mac Mail auto-completion:

Last week I posted a proposal for a new, LDAP centric, Java client. I'm pleased to announce that Neil Wilson will take the lead on creating a JSR "early draft" for submission to the JCP. In less than a week there's already momentum building around the proposal, evidently, this effort is long over due. Of note, Mark Wahl posted his views on the subject and broadened the scope of the proposal even further.

LDAP server development and usage is on the upswing. As Java developers attempt to take advantage of the full capabilities of modern directory servers, shortcomings in the built-in SDK are more evident than ever. Neil and I believe its high time to resurrect the call for a Java LDAP client. Its been done in the past (Netscape SDK, Novell, and so on) though this round we're shooting for standardization via the IETF or better yet a JSR. Interested? Let us know what you think.

Proposal for a Java LDAP Application Programming Interface

The Lightweight Directory Access Protocol (LDAP, as defined in RFC 4510 et al.) provides a standard means of communicating with directory servers. It is commonly used in identity management, authentication/authorization, naming services, user/application configuration, and general data storage. There are a growing number of commercial and open source server implementations, and many enterprises and service providers are significantly increasing the use of LDAP in their web applications, desktop clients, and mission-critical infrastructure.

While LDAP innovation and development continues on the server side the same is not true of the client. Java SE and EE clients typically use Java Naming and Directory Interface (JNDI) to communicate with directory servers. This is primarily because JNDI and the accompanying LDAP SPI are embedded within Java SE and is rarely based on the merits of the API itself. JNDI is intended to be a generic interface for accessing very different kinds of data stores, and as such uses an abstract API. As a result, critical LDAP functionality is difficult to access and the developer experience is significantly impaired. For example:

• The abstract nature of JNDI terminology is confusing for the LDAP neophyte. That is, the Java LDAP developer must learn 2 different vocabularies, LDAP and JNDI. For example, the terms "bind" and "unbind" have standard meanings in LDAP which are very different from the way those terms are used in JNDI. In addition, a given JNDI method may result in different LDAP operations based on the arguments provided (e.g., while most variations of the JNDI "search" method will result in LDAP search operations, one usage will result in an LDAP compare operation, which may have different semantics).

• LDAP functionality can be enhanced through the use of elements such as controls, extended operations, and SASL mechanisms, and such extensions are frequently described in new specifications. JNDI does not provide an adequate mechanism for adding client-side support for these elements.

• Standard LDAP idioms are difficult or exposed in a bizarre manner; e.g., failed operation codes must be parsed out of exception messages, search enumerations must be closed.

We propose the creation of a new Java API specifically designed for communicating with LDAP directory servers. An IETF draft addresses this subject and will likely serve as a starting point for future discussion as the the goal of this draft and our proposal are identical: a simple, developer-friendly interaction model for LDAP communication. In addition, the API should provide a convenient means of extending its functionality by adding support for new controls and extended operations as they are defined by various standards bodies. There have been successful implementations of the draft API in the past, but they were based on older versions of the Java language and as such did not not take advantage of recent improvements in Java performance and usability.

In many ways this API could provide for LDAP what JDBC has done for Java relational database clients. The beauty of LDAP is that it is a wire protocol, hence there is no need for vendor specific driver implementations. As such, a Java-based LDAP API could easily be self-contained and free of external dependencies, making it more immediately accessible to developers. Standardization will relieve LDAP vendors of the mundane and repetitive task of maintaining vendor specific client libraries and provide developers with a pleasurable LDAP experience.

Get the PDF proposal

A continuation of my previous post on pointing out the advantages of LDAP over relational databases. In this round I address fewer points though delve a bit deeper.

Universal drivers: No vendor specific database drivers are needed as LDAP specifies a standard wire protocol. That is, any vendor’s LDAP client should be interoperable with any other vendor’s directory server. Therefore, the onerous task of obtaining and managing vendor database drivers is no longer necessary.

LDAP controls: Controls provide a mechanism for both the client and the server to send additional information with a LDAP request. A very useful LDAP control is persistent search (not all servers support the control, but it is a common feature). This control notifies the search requester of a change in the search results. For example, if an application centrally stores configuration information in a directory it needs to be notified if the configuration is changed. This is easily accomplished by running a persistent search on the config data - if a change (add, modify, delete, move) occurs the server will asynchronously notify the client. Checkout controls supported by OpenDS.

Directory Service Markup Language (DSML): I'm sure I'll get ribbed for pointing out this one as I haven't seen any production use of DSMLv2 since its introduction in 2002. DSML is simply LDAP translated to XML (typically transported over HTTP). The primary benefits of which are: no LDAP client required, LDAP operations may easily pass through the firewall, and directory operations can be batched together and executed in a single request. We’re going to make interesting use of this capability in the near future with the introduction of a Javascript library that nicely models LDAP and talks DSML. The advantage? This will enable web developers to write browser-based applications that talk directly to OpenDS. Dare I say web 2.0?

URL based searches: Depending on the capabilities of your LDAP client, a standardized URL may be used to execute a search; e.g., ldap://localhost/dc=example,dc=com???(uid=treydrake) returns the entry associated with “treydrake”. With a bit of practice, fine grained entry/attribute retrieval and search criteria is easily expressed on the "web command line". Not quite ReST, but convenient nonetheless.

LDAP schema constructs: I've noted that LDAP schema consists of objectclasses and attributes. A point worth mentioning is that objectclasses are much more flexible than flat RDBMS tables. Specifically, there are 3 types of objectclasses: structural, abstract, and auxiliary. Structural types are concrete classes that represent an LDAP entry. Abstract classes are simply structural parents; i.e., they define attributes for inheritance by more specialized, structural classes. Finally, auxiliary types are supplemental classes that may be associated with structural or abstract classes. To make these concepts concrete consider the typical person example, "inetorgperson" (the LDAP standard defines numerous standard objectclass types, one of which is "inetorgperson"). This type is derived as follows: top -> person -> organizationalPerson -> inetorgPerson. Where top is the parent of all LDAP classes and inetorgperson defines new person attributes and inherits all superior objectclass attributes. Objectclass inheritance is a heck of a lot cleaner than defining numerous tables and linking them together with foreign keys!

Globally unique schema: An interesting aspect of LDAP schema is the identification of objectclasses and attributes as globally unique objects known as OIDs. That is, every attribute and objectclass has both a name and a unique ID. This makes sharing schema objects throughout the enterprise much more precise and traceable as an OID is associated with an authority (a company, standard, etc). For example, I may create an objectclass named "blog" with the OID 1.3.6.1.4.1.26922.1.1. OIDs are also hierarchal; breaking apart the OID, "1.3.6.1.4.1" identifies the object is owned by a private enterprise, "26922" identifies the specific enterprise and the trailing suffix "1.1" is completely defined by the enterprise. An enterprise, having defined a new globally unique object, may then publish a detailed description of the new objectclass for reference by consumers. Clearly, identifying schema elements with collision proof ids versus names is a distinct advantage. Need your own OID namespace? Get one here.