Directory standard at a crossroads
LDAP: Improving access to enterprise applications.
|
|||
 | |||
|
Advertisement: |
In the spring of 1997, then University of Michigan student Tim Howes walked into a roomful of software vendors gathered on campus and detailed a standard directory access protocol he had helped develop as part of his master's degree work.
By that fall, the protocol had broken out of academia, and every directory vendor had committed to adopting Lightweight Directory Access Protocol (LDAP), a standard for querying and updating a directory and an answer to the failures of X.500's overweight Directory Access Protocol.
Advertisement: |
Today, LDAP Version 3 (LDAPv3) is the foundation for a centralized enterprise directory available to any application.
Every directory vendor supports LDAP, and there are thousands of LDAP-compliant products that act as clients to those directories. The protocol has become the standard used throughout large companies to access directory information about users and resources.
"That meeting was definitely a watershed," says Howes, now CTO for managed service provider Loudcloud, speaking about the meeting in 1997. "Directories couldn't work without our client. The market was screaming for a standard client protocol."
But LDAP is clearly at a crossroads. Developers of the technology have answered the need for a standard way that clients can access a directory, and LDAP has cemented itself in corporate networks.
"LDAP has provided a lowest common denominator and the simplest way for us to get to the directory," says John Prince, core technology manager for connectivity at Conoco. The company relies on the protocol to make its directory available to other applications.
But Prince, like others, has been waiting for LDAP to standardize directory integration.
What LDAPv3 lacks is widely adopted access control and back-end integration extensions, such as replication, which are needed to integrate disparate directories and build a distributed directory service. Today, metadirectories solve that issue within a company, but the problems have mostly trapped LDAP behind the firewall. Experts say it will take help from emerging technologies such as XML to solve it.
Back to the drawing board
The Internet Engineering Task Force (IETF), the standards-body caretaker of LDAP, is working on resolving the protocol's lingering issues.
The IETF last month appointed an executive committee to review a backlog of 65 submissions for LDAP extensions. The IETF also suspended work in the LDAP extensions working group and moved its work on an access control model to the group working on LDUP - the LDAP Duplication/Replication/Update Protocol. LDUP is designed to provide a standard method for server-to-server and server-to-client replication. Secure access control is important when directories talk directly to one another to exchange information.
"Replication and access control are the two big-ticket work items but will take some time to see completion," says Kurt Zeilenga, co-chair of the LDAP Revision working group that is polishing the LDAPv3 specification to address ambiguities. "But LDAP is alive and well. There is untapped potential around LDAP, and we are moving into some interesting areas."
He says ongoing work in the IETF on authentication and security protocols, including the Simple Authentication and Security Layer and Start Transport Layer Security, will benefit LDAP.
But some observers say LDAP has stagnated, as evidenced by the fact that the LDUP group has not produced a standard during the past three years and that XML may be what provides the pieces LDAP has not.
"It is obvious that XML has become the way to exchange data in the future, and it's obvious that LDAP may have to take a back seat or go away at some point," says Dave Kearns, an independent consultant and Network World columnist.
LDAP now shares the stage with Directory Services Markup Language (DSML), an XML clone of LDAPv3. Directory vendor iPlanet already has its XMLDAP Gateway, which allows developers to build applications that use DMSL to perform LDAP operations.
Furthermore, emerging XML standards, such as Security Assertion Markup Language (SAML) and Extensible Access Control Markup Language, may supply access management features to complement LDAP and DSML, and eliminate the need for directories to replicate data to each other before they can interact.
"LDAP is not dead, but it has hit a plateau and will stay there a long time," says Daniel Blum, an analyst with The Burton Group and another Network World columnist. "We don't think the access control work will gain a lot of adopters because there are too many vendors with their own mechanisms."
XML may hold some of the answers.
DSML 2.0 provides a natural affinity with other XML work.
"We're excited about DSML. It puts LDAP in a protocol and coding [XML] that is everywhere," says Winston Bumpus, co-chair of the DSML working group and chairman of the Directory Interoperability Forum. "Small mobile devices won't need LDAP: They can use XML and Simple Object Access Protocol to communicate."
Others say that XML will fill other LDAP gaps.
"I think you will see more XML-based integration techniques adopted than LDAP extensions," says Patrick O'Kane, chief architect of ePresence, a systems integrator focused on directories. He says XML on the whole is being touted as the technology to integrate back-end systems, including the directory.
XML protocols, many not directly related to directory operation, may function a layer above the directory, to link access management servers, for example. In that case, those servers use XML to exchange preapproved authentication and authorization data pulled from the directories they are connected with using LDAP. The LDAP-compliant directories never talk to one another and don't require compatible access controls, replication or schema, which describe the directory structure.
It's less about integrating at the directory layer and more about integrating software that relies on a directory.
Emerging XML protocols such as SAML help foster that software integration, experts say.
"SAML can assert that authentication of a user has occurred and insert privileges. It assumes the receiver can consume SAML without having to know schema or protocols used by the sender's directory," says Jamie Lewis, president of The Burton Group.
LDAP requires that knowledge.
But he warns that SAML has schema and syntax issues of its own and that identity management systems such as Microsoft Passport or Sun's Liberty Alliance also have to be part of the mix.
"But SAML is a more loosely coupled environment. It won't be dressing up LDUP in XML," Lewis says.
Another important factor may be XML's path to the Internet. Companies typically open Port 80 to let data flow to the Internet. XML data passes through Port 80 on the back of HTTP. LDAP on the other hand uses Port 389, a port many IT executives are willing to open on their firewalls.
"The attraction to XML is that it runs over Port 80," says Jackson Shaw, lead product manager for Microsoft's Active Directory. "Companies that have that port open have tools to do content inspection on that port, not Port 389."
| ||||||||||||||
RELATED LINKS
