Integrating your information systems more closely with strategic business partners' can be beneficial. However, the key to any successful partner integration project is effective identity management, along with secure provisioning of user access rights. Businesses must control who has access to what information, and make sure that each partner organization can only access the information that it has privileges to use.
Directory systems help provide identity management and secure user access provisioning. Thus, effective directory integration and management is key for any large-scale partner integration project.
Partner Relationships
Business collaboration is driven by several market forces. Supply chain management is one such example—a company that integrates with its immediate upstream suppliers can manage inventory assets more efficiently by confirming orders, pricing information, and shipping dates. Private marketplaces, business-to-business exchanges, and other collaboration hubs are also good examples. These systems let participating organizations extend their relationships with current suppliers and dramatically reduce the costs associated with procurement administration.
The growing availability and maturity of Web services is also making it easier to integrate information systems between business partners. Companies are slowly moving their applications out from behind the firewall and onto the edges of their networks, where they can participate in dynamic, Internet-based transactions with customers and other business partners. Web services are rapidly transforming our notion of what an application really is. What was once a static clump of binary code is now a dynamic set of federated services specifically tailored to each user. The number of organizations using Web services to dynamically collaborate with business partners is small, but steadily growing. Companies like Merrill Lynch, Thomas Wiesel Partners, and Wachovia Securities have already had some notable successes.
How directory integration impacts your partnership management initiatives depends on the nature of your relationships. If you're only providing one set of services to a business partner, chances are your partner will only be authenticating against one directory. This makes system administration a relatively straightforward task, and directory integration is probably unnecessary in this case.
As your business relationships grow, however, you may want to make additional information services available to your partners. The applications that provide order confirmation, pricing data, and shipping date information services may all run on different systems in your enterprise, and users may need to authenticate against a different directory access with each service.
In such cases, directory integration could go a long way toward providing your business partners with a more pleasant end-user experience, and would save your enterprise time and money on system administration. Moreover, there may be businesses whose relationships with your company are characterized by several different roles—they may provide products for your supply chain in one role, and they may be a customer of your products and services in a different role. In these cases also, users may be accessing a variety of information services provided by your enterprise and authenticating against several directory services.
Directory Basics
A directory is a specialized type of database. Just like with a normal database, you can use directories to store and retrieve nearly any type of information. Directories, however, are usually optimized for being read from rather than written to. They are best suited for storing relatively static data, such as usernames or X.509 digital certificates.
A directory isn't typically deployed just as a single, stand-alone server, but rather as part of a broader network service. The notion of a directory service encompasses the directory itself along with a specific network protocol that clients use to access the directory. Directory services may also include a replication scheme for distributing data among participating servers and provide guarantees about the availability and security of the service on the network.
Directory services are nothing new, anyone who has been on the Internet has used a directory service at one time or another. DNS and email are perhaps the best-known examples:
- www.privacyright.com DNS is the directory service that resolves this host name into its corresponding IP address.
- [email protected] Privacyright.com is first resolved using DNS; then "paul" is resolved using a directory operating within a local—or possibly wider (perhaps global)—context.
DNS is a good example of a global directory service. It's distributed across a global network of cooperating machines and the DNS namespace is uniform. Directory services with a uniform namespace provide clients with the same view of the data no matter where the client is in relation to the service. In other words, no matter where you are on the Internet, DNS returns the same information in response to a query for newarchitectmag.com.
DNS also tolerates temporary inconsistencies when directory information is updated—up to 48 hours in the case of some zone transfers—as long as the directory information replicates to all participating servers and comes into sync eventually. Tolerance of temporary data inconsistencies during updates and replication is another feature that distinguishes directories from traditional data management systems.
Powerful as it is, DNS is only one of a whole range of directory services commonly used on computer networks. The most common directory service used in the enterprise for managing user identities, credentials, and access rights is a standard called the lightweight directory access protocol (LDAP).
LDAP began as a low-cost, PC-based front end for accessing X.500 directories. Based on the ISO/OSI networking standards, X.500 is an exhaustive, heavyweight directory model that defines a global namespace for addressing and locating objects in the directory. It also consists of a network protocol, known as Directory Access Protocol (DAP), for querying and updating directory information. Although comprehensive, X.500 is difficult to implement and maintain because of its complexity, and full-blown DAP clients were often too large to install and run on smaller computer systems like PCs.
LDAP was developed at the University of Michigan, with support from the Internet Engineering Task Force, in the early 1990s to make it easier for PCs and other modest computer systems to browse and access the information stored in an X.500 directory. One of the biggest obstacles to acceptance of X.500 and simplifying access to the directories involved the DAP protocol—specifically DAP's reliance on the OSI network protocol stack. Due in large part to its complexity, the OSI stack never really gained widespread acceptance. LDAP simplifies directory access by letting clients connect to directory services directly over the much more widely adopted TCP/IP stack, making the directory services available on LANs, WANs, and the global Internet. LDAP also dropped many of the more esoteric and infrequently used features of the DAP protocol, which made the specification much easier to implement in client software.
So on one level, you can think of LDAP as a lightweight information access protocol much like many other common Internet protocols. You can use LDAP to access and browse X.500 directory information (by default, on port 389) much like you can use HTTP to access and browse Web documents (by default, on port 80).
But LDAP is more than just a lightweight version of the bulky DAP networking protocol. LDAP inherits its data model essentially unchanged from X.500. The LDAP directory service model is based on the concept of entries. An entry is a collection of descriptive attributes. Each attribute has a name, type, and one or more values. For example, the attributes that describe a person might include the person's name (common name, or cn in our example), telephone number, and email address.
For example, the entry for Paul Sholtz might have the following attributes:
cn: Paul Sholtz email: [email protected] telephoneNumber: 650-555-1212
LDAP arranges directory entries into a hierarchical, tree-like structure, starting at a root and then branching down into individual entries. At the top levels of the hierarchy, entries represent large organizations. Underneath these, the directory entries might represent smaller organizations. The hierarchy usually ends with entries for individual people or resources. See "Hierarchy of Entries in an LDAP Directory Service" for more information.
Each entry is uniquely identified by a distinguished name. A distinguished name consists of a unique identifier specifying a particular entry at some level of the hierarchy (for example, in "Hierarchy of Entries in an LDAP Directory Service," paul and john are different user IDs that identify different entries at the same level) and a path that traces the entry back to the root of the tree.
The distinguished name for the paul entry might look like this:
uid=paul,ou=employees,o=privacyright.com
Here, uid represents the unique identifier that specifies the entry, ou represents the organizational unit in which the entry belongs, and o represents the larger organization containing the entry.
Although many commercial directory products on the market today support LDAP—most notably Active Directory from Microsoft—it isn't unusual to find legacy directories scattered throughout the enterprise. NT 4.0 domains, NDS, and Lotus Notes are all common examples. Understanding LDAP nevertheless gives us a good picture of what directories are good for and where their limitations lie. Directories can manage relatively static information, such as user authentication credentials, but they weren't designed to replace relational databases, traditional file systems, or DNS.
