A report on the current directory standardization activities will be presented. The report will cover LDAP and X.500, and related activities. The future of directory standardization will also be discussed.

Slides...

Kurt's primary focus is Internet technology and standards development in the areas of distributed information systems, distributed security systems, and network security services. Aside from Kurt's obvious interest in directory technologies, he is interested in the areas of Internet security services, especially as used to secure application-level protocols.

Kurt is an active participant in the Internet Engineering Task Force (IETF). He is authoring and/or editing numerous Internet-Drafts. A few of his drafts have become RFCs. Kurt is currently co-chairing the Simple Authentication and Security Layer (SASL) working group. Kurt is also a member of the LDAP Directorate and Security Directorate.

Kurt is currently a development engineer at Isode Limited. Kurt is an advisor to the OpenLDAP Project, which he founded in 1998.

Traditionally LDAP directory servers have been used over RDBMs for fast, high-throughput read access to the data. But as LDAP offers a standard protocol, object oriented data model, more applications are built for LDAP and are starting to demand a higher throughput of writes to the data with constant and fast response time. Realizing that servers designed over a decade ago for fast reads needed a serious facelift, and leveraging its long experience with LDAP, Sun decided to redesign and write a new LDAP server that would provide a leapfrog in term of write performances and throughput.

Released as an open source project OpenDS is this new LDAP based directory service. For ease of development and portability OpenDS was written in Java. While Java has traditionally not be considered as good for performance, it is in fact a very good platform for building scalable server with very high performance. Based on a Java database implementation, OpenDS has a simple and modular architecture, provides many interfaces for extensibility. While still in development of the first release, it already implements many RFCs while providing many of the Sun Directory Server features such as Multi-Master Replication, Access Controls. Some of its features include advanced grouping services, better security, especially around Passwords... The version 1.0 is scheduled to deliver an LDAP directory server in the last quarter of 2007 but future versions will include advanced services such as virtual directory capabilities, proxy capabilities and synchronization withother services.

As of today the OpenDS community is mostly a community of users who are embedding OpenDS in their applications, products or testing environment, while the 22 code committers are Sun employees. It is a young but growing and responsive community. Visit the project website at www.opends.org, see how much documentation is available on the wiki, and contribute to it, either with tests, use case scenarios, documentation, extensions or code...

Slides...

Ludovic Poitou is a Software Architect in the Directory Services engineering team, based in Grenoble, France. For the last 12 years, he has been designing and developing the Sun Directory products (from Sun Directory Services 1.0 to OpenDS), working in all areas from management tools, to client libraries, protocols, security and multi-master replication. Ludovic has participated in the LDAP standards at IETF and the Directory Interoperability Forum from The Open Group. Mr Poitou blogs on the subject of Directory Services, LDAP and Identity Management at http://blogs.sun.com/Ludo.

This talk will cover some of the more significant enhancements available in the new OpenLDAP release. Features such as multi-master enhancements for Syncrepl replication, enhancements to the dynamic configuration and monitoring backends, and overall performance enhancements will be described. Recent benchmark results will also be presented.

Slides...

Howard Chu is a founder and the Chief Architect of Symas Corp. Howard has been a core team member of the OpenLDAP Project since 1999 and became the Project's Chief Architect in early 2007. He has been a significant contributor to dozens of free and open source software packages over the past twenty+ years and has been instrumental in steering the development of OpenLDAP.

Directory technology is an indivisible cornerstone in computing science and LDAP specifically is essential in several industries however it is severely underutilized. One would expect the demand for LDAP to increase as infrastructures and the Internet grow, with more boundaries, nodes, services, users and ways of doing business emerging rapidly. Directories inherently solve integration problems yet more integration problems appear while complexities of existing problems are compounded. We're not witnessing a proportional increase in the adoption rate of directories; namely LDAP directories. This is not a coincidence. It is the result of a lack of several factors: tooling support, courses on directory technology in academia, qualified domain experts and rich integration constructs. More specifically, information architects and key decision makers incorrectly choose to apply ad hoc solutions to problems rather than opting to using directories. If these limitations are removed then there would be greater comfort, flexibility and adoption. LDAP could do more than it does today namely in the area of provisioning and workflow. LDAP could potentially experience a Renaissance with renewed interest due to increased demand to solve the classical integration problems it was designed for and beyond. We discuss these limitations, and the proposed means to remove them, all in an effort to express our vision at the Apache Directory Project. Our aim is clear; we intend to influence and incite other directory implementers and projects by our example to trigger what we envision as the Modern LDAP Renaissance.

Alex Karasulu is a member of the Apache Software Foundation and the original founder of the LDAPd Group and the Apache Directory Project http://directory.apache.org. He founded these open source efforts to modernize LDAP with rich integration tier constructs like views, stored procedures, and triggers with the ultimate aim to increase it's adoption and utilization. Apache Directory demonstrates his vision.

Starting in 2006, Regional Computing Center Erlangen (RRZE) at Friedrich-Alexander University Erlangen-Nuremberg began a project to reconstruct the existent user management. One of the early tasks was to find a useful schema for the new central directory service. In addition to the schema provided by the identity management (IDM) software, as many standard schemas as possible should be used.

This paper will describe the experience about gathering and consolidating information about existing LDAP schemas. The current lack of a comprehensive summary and best practices will be eliminated by a reference schema for LDAP-based identity management systems. The presented reference schema will allow the comparison of the standard and widely published schemas. It will provide mappings, lossless where possible, for equivalent attributes with different syntax or different domain, e.g. through additional constraints like enumeration types. Own earmarked schemas can be derived from the reference schema. Mapping to any other included schema are given through the relationship to the reference schema.

The most important steps of schema design process have been retained and written down. The paper will provide a realistic example of this process and shows the simplification given by the use of the reference schema. A review of the schema design process in the project above, will discuss some restrictions of this appliance. A prospective tool-based mapping for data exchange between different identity management systems will complete the paper.

Slides...

Dipl.-Inf. Frank Tröger is an employee of Regional Computing Center Erlangen (RRZE) at Friedrich-Alexander University Erlangen-Nuremberg since February 2005. During study he already worked as assistant scientist for the user management group at RRZE. Since 2005 he was a member of the mail group and used directory services for university-wide mail routing. Since November 2006 he is a member of the identity management project. Mr. Tröger is intensely engaged in schema design process and is responsible for the schema in the project. Since February 2007 he is an external PhD candidate at Dept. of Computer Science 6 (Database Systems) with research interests in identity management.

Prof. Dr. Klaus Meyer-Wegener has been a Full Professor of Computer Science (Database Systems) at the University of Erlangen and Nuremberg since October 2001. From 1975 to 1980, he studied computer science at the Darmstadt Institute of Technology and finished with the degree of Diplom-Informatiker. After that, he became a research assistant in the Department of Computer Science at the University of Kaiserslautern. In 1986, he received a Ph.D. (Doktor-Ingenieur). He remained at the Department of Computer Science of the University of Kaiserslautern as an assistant professor (Hochschulassistent, C1). From Oct. 1987 to Dec. 1988 he was granted a leave to work as an Adjunct Research Professor at the Naval Postgraduate School in Monterey, California. In 1991, he finished his habilitation at the University of Kaiserslautern. From 1990 to 1993 he was Associate Professor of Computer Science (Database Systems) at the University of Erlangen and Nuremberg. Then he left to become a Full Professor at the Department of Computer Science of the Dresden University of Technology where he stayed until 2001.

A solution for an Access Control List (ACL) providing a secure, reliable, rugged, satisfactory flexible and easy to customize OpenLDAP authorization rule set is discussed in this paper.

The development of this sophisticated ACL set has its origin in the IntegraTUM project currently established at the Technische Universität München (TUM) in co-operation with the Leibniz Supercomputing Center Munich (LRZ). IntegraTUM is a research project focused on strategies regarding the realignment of information and communication technology (ICT) at German universities in general. It is accomplished under the guidance of the Chief Information Officer (CIO) in compliance with the overall IT strategy of the TUM.

The TUM incorporates about 8800 employees with their fiscal data stored in SAP HR. The HIS SOS system manages approximately 21000 students' data records. Both systems have been successfully connected to our identity management system, so an identity’s core information (e.g. name, uid ...) is already available. Digital identities of students and employees can easily be differentiated based on their data source. For students generally the HIS SOS internal categorization (e.g. branch of study) is mostly sufficient for authorization.

The fiscal information provided by SAP HR was rather intended to be used for calculation of salaries than for authorization purposes useful for subordinated IT-systems. So the information about employees needed for authorization by our IT-systems is partially incomplete, inexact and seldom reliable enough to be used for fine-grained automated authorization. Often neither exact positions nor individual responsibilities for any kind of IT-system access (e.g. webmasters of faculty X) can be acquired or determined adequately. Other data records especially regarding each individual's exact location on the campus seem to be out-dated, too. A common cause for this situation is for example that an organizational unit that has successfully raised funds for a new research project is often not imperatively congruent with that project's employees' fiscal affiliations regarding the actual organization of the university.

Furthermore, to build heterogeneous and cross-departmental research teams an enhancement has to be sought-after to offer a possibility to categorize employees according to their effective belongings. Centralized assignment of all employees into each ones' (also multiple) organizational units is complicated, error-prone, time consuming and highly probable resulting in suboptimal data quality. An optimum can only be reached by distributing (delegating) the workload regarding the assignment down the organizational hierarchy closer to the actual destination of every employee's position. The idea behind the IntegraTUM Group Management Application (iGMA) was born.

It has been decided to develop iGMA for mainly three purposes.

1. iGMA allows a free categorization not only restricted by means of affiliations. Thus staged access permissions can be associated as flexible as needed.
2. The deployment of iGMA offers the (multiple) categorization of all TUM employees in a rational and very effective way, considering the given organizational structure.
3. In parallel the most reliable data quality will be attained using the locally available administrative knowledge. Thus a mechanism for role delegation is a very important feature.

The distributed management access enforces the implementation of a mostly restricted but preferably flexible ACL model. Thus an ACL set offering hierarchically delegable roles for group management has been designed. This paper illustrates iGMA's basis, which is ready for operation. The underlying concept regarding the ACL set offering role based access control and further more delegation of role ownership downwards the organizational hierarchy will be presented and explained in detail. Once the idea underlying the ACL set has been internalized, the concept is easily adaptable for any OpenLDAP-enabled application in general.

iGMA roughly consists of two major components, a directory server and an according front-end. The component that is visible for an administrator is the dedicated front-end. It is a yet in development (web based) Graphical User Interface providing access for administrators to manage group objects and their members. Its main objective is to support group administrators by guiding them through their daily tasks, generally covering administration of groups and delegation of roles. Also, the front-end takes care to obey the defined processes. Convenient usability and control of the iGMA internal workflow represents another feature. Any further details regarding the use cases considered by the front-end implementation will not be a topic here.

The directory server as the other component represents iGMA's fundament and is based on an OpenLDAP server which is implementing restrictive ACLs. The focus of the directory service lies on security and access control aspects. For example the creation/modification of unnecessary/predefined directory objects should be handled as restrictive as possible. Hence the basis of iGMA, that means the underlying structure of the directory service in general and the elaborated ACL set in particular used to support iGMA's internal authorization processing both for groups and roles will be presented. The resulting advantages and possible limitations of our solution will be addressed, too.

Slides...

Daniel Pluta is 32 years of age and has available about 12 years experience regarding large-scale enterprise IT-infrastructures. Currently he is employed as a Ph.D. candidate at Technische Universität München (www.tum.de) for the IntegraTUM project under guidance of Prof. Dr. Bode (Vicepresident and CIO of TUM) located at the Leibniz Supercomputing Center Munich (www.lrz.de).

His primary topics of interest are communication and management processes within (virtual) IT-infrastructures in general as well as network- and system-security in particular. Before Daniel started his scientific career in 2005 he worked for a major German automotive group's IT department responsible for network management and internet security.

His passion besides Public Key Infrastructures (PKI), any kind of Virtual Private Network (VPN) technology and tracking various opensource projects is skiing in the french alps.

The Shape of an Directory Information Tree contributes much to the success of an LDAP Project: a well designed structure can grow without problems, but if you are challenged for the first time, it may be difficult to design the right tree at first, given the great flexibility of LDAP. How many containers? How deep has to be the Tree? What kind of Information should we store in them? We analyze the factors to take into account when designing a DIT and we discover they are not always related to the organizational structure.

Slides...

Dr. Giovanni Baruzzi has been active for the LDAP since 1998. He designed Directories for many Organizations in both the financial and public sectors and held courses about LDAP. Today he concentrates in the Identity Management Technologies. He is member of the GenericIAM Initiative.

Syntlogo GmbH specializes in the design and deployment of Identity Management. Syntlogo delivers design and implementation of Identity Management Solutions and restructuring of LDAP installations. The company is based in Sindelfingen and operates Europe wide.

Apache Directory Studio, a sub-project of the Apache Directory project, is an LDAP and Directory tooling platform. Written as an Eclipse RCP application composed of several plugins, it runs as a standalone multiplatform application (Linux, Mac OS X and Windows) or integrated within Eclipse itself.

In this session, we will outline the design of the tool suite and describe its three most important features:

• The LDAP Browser Plugin is a tool for browsing, searching and editing entries on an LDAP Server. It works with any LDAP Server.
• The Schema Editor Plugin is intended to edit the schema of an LDAP Server (object classes and attribute types). The Plugin can dynamically edit the schema of an Apache Directory Server and load/save schemas from/to OpenLDAP schema format files.
• The Configuration Plugin for Apache Directory Server can be used to edit the configuration file of the Apache Directory Server.
• The ACI Editor Plugin enables the user to configure Access Controls of the Apache Directory Server.

This talk will provide live demonstrations of the capabilities against different LDAP servers.

Slides...

Stefan Seelmann is a software developer and consultant, he is working on identity management projects. He is an active committer and PMC member of the Apache Directory project and focuses on the development of Apache Directory Studio.

Pierre-Arnaud Marcelot is a software engineer at Iktek, a french open-source oriented consulting company. He is an active committer on the Apache Directory Server Project for more than a year and he has been involved in the development of Apache Directory Studio, a complete Directory tooling platform based on the Eclipse RCP framework intended to be used with any LDAP server however it is particularly designed for use with the Apache Directory Server.

A Directory Service should be no different to what you have come to expect from your phone service; that is fast, reliable and not requiring any knowledge about how it is laid out. All the routing, switching, fail-over and load-sharing are handled by the backbone without any client involvement. The same seamless operation should be expected from a Directory Service. Your LDAP client should not need to be aware that the backbone is distributed or has failed over to an alternative server.

How does a Directory Backbone Service deal with LDAP clients as well as LDAP servers from many different vendors? The secrets of a seamless Directory Backbone Service include the following:

• Adherence to Standards, such as LDAP, x.500, and SNMP;
• High Speed Switching and Routing to chain queries across the network;
• Distributed Searches for finding of results across many servers with a single query;
• Concurrent Replication which guarantees data consistency between servers;
• No service while recovering to ensure that a client can never receive out-of-date information;
• Views that add a layer between the LDAP clients and the directory servers to combine multiple LDAP searches into one search

The Directory Service that implements these features enables the Backbone to be available, scalable, consistent, maintainable and extendable.

In this session you will find out what really happens under the covers...

Slides...

Hilla Reynolds, Director of Development, has managed CA’s Directory development team since early 2001. During that time CA Directory has achieved many milestones, including: OpenGroup LDAP Certification V2.1 and 2.2; independent verification of 15,000 searches per second in 2004; a billion searches per hour on a 25 Million entry directory in Feb 2007; Common Criteria Certification EAL3 in May 2007; and deployments at customers with over 100 million entries in their directory backbone. Hilla’s role includes project and people management, integration with other CA products, product planning, and process improvements. Hilla was instrumental in getting first her lab, then all of CA R&D, ISO9001 certified. She completed two Lean 6Sigma projects in 2006.

Before CA, Hilla was Product Services Manager, and later Customization Manager, at Siemens Research, later acquired by Open Telecommunications. Hilla discovered her passion for process improvements and test automation, and managed the design and implementation of an internal Test Case Management System, as well as customizations to the Network Provisioning Product Capacity Integrator.

Previously Hilla spent over 14 years at Email Electronics, where she started on a team of C programmers working on an innovative truck-stop system deployed across Australia. While looking after her young family, Hilla worked part-time on the design, implementation, documentation, and packaging of a successful fleet system. Later Hilla held the roles of RDBMS Architect, Development Lead, and Principal Engineer, all focused on “Omega”, an Oil Terminal Automation System deployed world-wide.

Hilla studied Mathematics and Information Technology and graduated in Köln in 1978. She worked for Bayer AG as a Fortran 4 Programmer until emigrating to Australia in 1980. There she joined CRA as a Fortran 77 Programmer; she worked on scheduling software for the Australian Air Force, and designed and developed a statistical survey system for the Australian Bureau of Statistics.

Most people that tried to to any serious LDAP client programming in Java would agree that this is not a very pleasant experience. The JNDI API is very similar to other built-in Java APIs in a number of less flattering ways:

1. Lots of plumbing code is required to perform even the simplest of tasks.
2. Pedantic resource cleanup is essential to prevent connection leakage.
3. Exception handling is verbose.

All in all it boils down to this: LDAP programming in Java is dull, repetitive and error-prone.

Spring LDAP is a library that tries to address these problems. It relieves the programmer from the tedious plumbing code traditionally needed in Java LDAP programming, enabling him to focus on the important stuff – where and how to find data (DNs and Filters) and what to do with it (map to and from domain objects, create, modify, delete, etc.).

Inspired by the template approach used extensively throughout Spring Framework, this library encapsulates all the plumbing code, such as creating DirContext instances, looping through NamingEnumerations and cleaning up resources. It also provides utilities for working with Filters, Attributes and Distinguished Names, and finally it also taps into Spring Framework's transaction management, enabling client-side transaction support for LDAP.

Spring LDAP is an open source project hosted on Sourceforge as a Spring Framework sub project. It is licensed under the Apache License version 2.

Slides...

Mattias Arthursson is co-lead of the Spring LDAP project. He works as senior Java consultant for Jayway, Sweden's leading Java consultancy.

While working in an LDAP intensive customer project he became inspired by Spring Framework and started introducing the first template ideas that lead to Spring LDAP.

These ideas were later reworked, generalized and made public as the LdapTemplate project at Sourceforge by Mattias and his colleague Ulrik Sandberg. Since it was inspired by and is very similar in philosophy to Spring Framework the LdapTemplate project was adopted last year as a Spring Framework sub project under the name of Spring LDAP. Spring LDAP is maintained by Mattias and co-lead Ulrik Sandberg.

LDAP is commonly used as a repository for data about objects, particularly users, of relevance to the operation of an enterprise's computing resources and applications. However, there is a strong tendency for newer application protocols and their data payloads to be defined in an XML schema language for rendition as XML documents. Such applications typically have a need for the kind of user and other object data that has traditionally been held in the entries of an LDAP directory service, as well as defining new kinds of structured data to be associated with those same objects, for example Security Assertion Markup Language (SAML) assertions. There is a clear advantage to data consistency and ease of administration in having a common directory service for all of an enterprise's applications, whether or not they are based on XML. Unfortunately, the core LDAP specifications have no inherent support for XML formatted object data or XML formatted protocol messages. This paper identifies four approaches to marrying XML with LDAP directory services and discusses the advantages and disadvantages of each approach with respect to simplicity, utility, uniformity and extensibility.

The first approach encompasses ad-hoc solutions using the existing LDAP framework. For example, embedding XML documents in directory attributes with a string syntax (e.g., Octet String or Directory String), or defining specific-purpose syntaxes and matching rules.

The second approach includes LDAP-inspired XML-based directory protocols such as the Directory Services Markup Language (DSML) version 2 and the Service Provisioning Markup Language (SPML), which may be readily implemented as alternative interfaces to the directory service.

The third approach involves XML-based registry or discovery services, as exemplified by ebXML Registry Services and Universal Description, Discovery and Integration (UDDI), which bear no particular relationship to LDAP, but provide a similar function and can be considered to be competing against LDAP.

The fourth approach is the XML Enabled Directory (XED) framework, which is a collection of extensions to ASN.1, LDAP and X.500 designed to seamlessly support XML within the LDAP/X.500 directory model, for both data and protocol. This paper shows how XED achieves most of the advantages of the other approaches while avoiding their more serious drawbacks.

Slides...

Dr. Steven Legg is currently employed as product architect and lead software engineer for eB2Bcom Pty. Ltd. with a primary focus on directory systems and related technologies. He first began implementing directory systems in 1987 following the X.500 standards and currently works on implementations of both X.500 and LDAP. Steven has been active in LDAP standardization within the IETF since 1999 and has authored six RFCs related to LDAP. He has an on-going interest in harmonizing LDAP, X.500 and other discovery and registry services, and in extending the capabilities of LDAP and X.500, particularly into the realm of XML technologies.

LDAP-based services have been gaining momentum as a decisive technological concept over the last years and are now central and often business-critical building blocks of many corporate data centers.

While said directory topologies have been evolving constantly, typically offering state-of-the-art features (e.g. data distribution, reliability, scalability), little progress has been made on the client side, i.e. the LDAP-enabled applications that use the directory services as clients. The quality of the code that implements their LDAP interfaces varies from highly sophisticated to poorly designed or conceptionally outdated (e.g. no capability to follow referrals). LDAP proxies can be the answer to these shortcomings: on behalf of their clients, proxies can transparently follow referrals, automatically fail over to other directory instances, and load-balance incoming LDAP traffic.

But there are more good reasons for considering the deployment of LDAP proxies.

Acquisition and data consolidation scenarios usually generate demand for a transparent view of the available data at any stage of the merging process, regardless of how the data is distributed and organized. Typically, DN (Distinguished Name) mapping features of LDAP proxies would be the concept of choice to build a common virtual tree from all existing repositories and thus cope with said demand. LDAP proxies may even be capable of mapping external namespaces (Data Information Trees) into a common virtual and transparently searchable view.

Product migration and upgrade scenarios are other good examples, where a proxied (virtual) directory topology facilitates - via DN and attribute/objectclass mapping - the representation of different schemata and DITs to old and new applications during migration and transition time.

While many load balancing switches offer an LDAP health check mechanism, efficient LDAP load balancing based on type of operation (BIND, READ, WRITE) is a challenge which can only be met using intelligent directory proxies.

Directory server products implement security and access control mechanisms non-uniformly. In a heterogeneous LDAP environment, LDAP proxies can act as intelligent choke points between LDAP clients and the different directory server backends, using specific connection classes to create multiple criteria for accepting or denying the routing of an incoming request.

This lecture presents the above mentionned LDAP virtualization scenarios in greater detail and identifies the necessary LDAP proxy feature set to implement the requirements of said scenarios. General LDAP virtualization design approaches and recommendations are presented as well.

Slides...

Andre and Cengiz have been working in the LDAP and directory server realm for many years. As Sun Professional Services software architects, they command in-depth knowledge of LDAP and directory technologies, combined with manifold projects experience. They have been designing and implementing directory and identity management solutions of any severity and complexity for a wide range of customers.

LDAP directories lack stored procedure and trigger facilities which have been provided by relational database management systems for many years. The need for these rich integration tier constructs drives information architects towards the use of relational databases for managing centralized information that would have best been served by directories. A novel model for specifying stored procedures and triggers in LDAP directories is presented. Rather than introducing incompatible changes to the protocol, these features were designed by making use of LDAP extension points. LDAP stored procedures allow users to define their own server side routines and to call them via an LDAP extended operation. LDAP triggers raised by standard LDAP operations invoke LDAP stored procedures. Triggers can be defined on individual entries or on sets of entries using subtree specifications based on the X.500 administrative model adopted by LDAP. The proposed models have been realized and tested within the Apache Directory Server.

Slides...

Ersin Er is a Ph.D student at the Department of Computer Engineering, Hacettepe University in Turkey. He is an active committer and PMC member of the Apache Directory Project. He has been working in the project for more than two years and he has been involved in implementing various appealing features of ApacheDS like LDAP Stored Procedures and Triggers.

The IT infrastructures in the industries have been undergoing significant changes over the last couple of years. Where relational databases constituted the central repositories for critical business applications in the past, we now see LDAP-based directories taking over this role. This paradigm shift is owed to both technical and commercial aspects: straight-forward deployment of directory services on the one hand side and cost saving considerations on the other. But even with the aspect of reduced costs, no responsible IT decision maker would even consider said shift without availability, reliability and scalability features - which she or he is accustomed to from their relational databases past - being built into the new directory service architecture.

Over the last ten years, Sun Microsystems Professional Services have been involved in many directory deployment projects ranging from small to extremely large. Especially the latters - typically found at telecommunication providers and international enterprises - showed high demands on making the directory service "application ready" in 24x7 environments.

A flexible, feature-rich though standards-conform directory product and expert knowledge of LDAP architecture & design practices are the foundation on which such large deployments are being built. But there is more: substantial understanding of operational aspects such as networking, load balancing, backup/restore mechanisms and disaster recovery are decisive factors, too.

Not surprisingly, application requirements and the size/amount of data being handled govern the topics to focus on.

In data centers with hundreds of UNIX systems, a directory service may become the central hub for consolidating and centralizing naming services. While data characteristics (size and number of entries) are usually negligible in such a scenario, the client access patterns of the various UNIX derivats introduce significant challenges to availability and responsiveness of the directory service.

In service provider environments the access patterns are predictable, though, revolving around authentication and retrieval of user profiles. The real challenge with these environments is the size of the directory data, starting at one million entries and going up to several hundred millions. Obviously, data provisioning and management, as well as backup/recovery strategies, high availability and scalability approaches are the challenging topics here.

Lessons learned from these different challenges motivated Sun Professional Services to develop a reference architecture, a deployment guide and according tools, which have been (re-)used in many of the directory projects Sun was involved in.

This presentation will outline the challenges of typical high-scaling directory deployments, present and explain the architectural approaches chosen (including some advice on best practices), and finish with recommendations on deployment and implementation aspects.

Slides...

Abdi and Robert have been working in the LDAP and directory server realm for many years. As Sun Professional Services software architects, they command in-depth knowledge of LDAP and directory technologies, combined with manifold projects experience. They have been designing and implementing directory and identity management solutions of any severity and complexity for a wide range of customers.

Specifically, Abdi was the fundamental driving force and lead architect of a Sun-internal LDAP initiative that aimed at designing a highly-scalable directory reference architecture, termed "eLDAP", for very large deployments (e.g. at telecommunication companies, ISPs, large, international enterprises).

The FederID project is a complete open source identity management and identity federation software. It is based on Liberty Alliance and LDAPv3 protocols. The goal is to provide an easy installation and an unified customization of the following free software:

• Lasso and Authentic: Liberty Alliance library and its Identity Provider.
• LemonLDAP::NG: WebSSO with Apache (ObjectWeb project).
• InterLDAP: Advanced LDAP directory administration and content management (ObjectWeb project).

Authentic is written in Python and is a standalone Liberty Alliance Identity Provider. It interacts with an LDAP directory.

LemonLDAP::NG is a full WebSSO solution with authorizations based on LDAP requests. It can handle Liberty Alliance authentication, trough Authentic.

InterLDAP is a middleware for identity management, completed with management tools. It is divided in sub projects, all designed for one objective: to manage electronic identities, from their creation, trough their life in the organization, until their deletion or archival.

On project is LAAP : Liberty Alliance Attribute Provider, which build a bridge betwenn an LDAP directory and a Liberty Alliance circle of trust, by exposing user attributes in this ciricle.

A second component named LSC (LDAP Synchronization Connector) is aimed at exporting data form databases so as to store (or update) them in the LDAP directory. It is independent from other sub projects.

A J2EE web interface is provided, named WUI: with the help of an enriched schema, stored in the LDAP directory, it displays the data (as a white pages application) and allows modifications. These modifications are linked to the enriched schema, which sets for example the values allowed for an attribute, it's syntax, the default values...

Slides...

Clément OUDOT is member of the LDAP expert team in LINAGORA, a French firm which business is based on open source technologies. He achieved an entire reorganisation of directories architecture at the financial ministry of France, integrating OpenLDAP with technical add-ons coded by LINAGORA's engineers, reversed next to the community. His knowledge in monitoring solutions enabled him to publish many scripts and tutorials to follow the activity of LDAP directories with well-known free software like Nagios and Cacti. He is the leader of the FederID project and is involved in other research and development projects.

The authors administer the Greek School Network Directory Service which contains school, teacher and student accounts. User administration is done through a feature-full web administration interface which includes features like:

• Creating attributes based on the value of other attributes.
• Performing post operation tasks like creating user directories, sending welcome emails and so on.

Greek School Network is moving towards the e-school framework which apart from the currently available services will include:

• A web portal (sPortal) for student parents.
• A school administration platform which will move all school operations (student enrollment, classroom management, grading) to the electronic world.

• Each service only has knowledge of it’s own little world. The sPortal just needs to create simple parent username/password for access to the Portal. It is not concerned with the fact that the created account might also be entitled to email or VoIP access.
• There is no way to perform post operation tasks like creating user directories.
• Each service is given too much power over the Directory Service. There’s almost no control (apart from ACIs) of what is added to the directory and no constraints can be set on the incoming attribute values.

We decided to overcome the above difficulties by creating a web service interface around the already existing user interface. The web service uses WSDL and SOAP over HTTP(S) to create a function interface to all abstract operations needed by the external services. Each time a parent has to be created in sPortal, the portal will call the CreateParent() function with appropriate arguments. This function will perform all necessary checks on the arguments and call the internal object creation function of the user administration interface. That way:

• We use the same function backend for both the user administration interface and the web services.
• Complete and configurable logging of all operations is available with much more detail than that provided in LDAP server logs.
• Computed attributes values are available using any valid php function or expression for computing values.
• Pre and Post operation tasks can be performed through the backend (which can call outside scripts or other web services).
• All operations pass through a single point where we have complete control over what happens and by whom. We can set constraints on attribute values and do extra checks on these values.
• Outside services don’t need to have deep knowledge of our entry scheme. They just need to call already defined functions (with the minimum set of arguments) and the web services/backend handles the rest. We are free to change the entry scheme whenever we want, adding or removing computed and static attributes to the ones sent by the web service.
• We can impose our own entry expiration policy. The EntryDelete() web service function might end up just setting an active=false attribute inside the entry allowing us to decide when to actually delete the entry and/or perform any other tasks necessary.
• A clear, precise and minimal function interface is exported to outside services instead of an abstract protocol like LDAP which demands creating agreements between the Directory Service and outside services on how to perform operations.

A PHP API has also been created as a backend for these web services called LDAP User Management Service (LUMS). It basically provides a set of basic API functions (search, add, delete, modify, rename, change password), and a strong configuration language. The language allows the administrator to define ldap object types along with their corresponding attributes. For each attribute a number of options is available:

• define an attribute as required, multivalued
• set the attribute type (string, binary, dn, telephone, mail etc)
• define the attribute type. Can be user inserted, constant, auto increment, function created
• allow for attribute uniqueness
• define extra syntax checking functions
• automatically handle auto incremented attribute values
• define virtual attributes which are used to create attribute mappings

Moreover, pre and post operation functions can be defined while the interface takes care of handling non English char-set attribute values. The authors believe that LDAP and XML integration will be even more tight in the future. DSML is already available and the XML Enabled Directory Internet drafts envision moving all LDAP operations to the XML space. Creating a Web Service function interface around a Directory Service can prove highly beneficial in centralizing control of ldap write operations while providing a lightweight, well-known, clean and minimal interface for outside services to use.

Slides...

Kostas Kalevras is a network engineer for the Network Operations Centre of the NTUA. Among other things he is in charge of the LDAP and RADIUS services for the NTUA, Greek School Network and GRNET. He is also a primary developer for the FreeRADIUS project having both developed and maintained a large number of server modules as well as the web based administration front-end dialupadmin. He is also participating in other RADIUS related open-source software projects.

This presentation explains the best practises for getting the highest performance out of LDAP applications. Through many years of different customer engagements, Felix has seen the good, the bad and definitely the very ugly LDAP applications and pin-points common mistakes that many application developers make when have their applications talk to LDAP servers. In this presentation, several examples are provided, with some code extracts, log files, traces, and an analysis what goes wrong, and why. Solutions are then described to address those issues and expanded into best practises in order to eliminate those problems in the future.

Common pitfalls are also addressed, with explanations on why developers typical fall into the traps of writing very inefficient code. Often it is because of a particular challenge that developers try to circumvent (such as rapidly refreshing data, handling multiple credentials, recovering from errors). For these common challenges, solutions are given as well that are not just elegant, but very efficient.

The first example focuses on LDAP connection management and focuses on several applications that make multiple requests to the LDAP servers, but disconnect and rebind every time. This puts a lot of stress on the TCP stack of the LDAP client and server, and reduces the server's performance - especially when the amount of connections are high. Code fragements are then presented on how to achieve proper connection pooling as a solution for this problem.

Example 2 is called "Doing everything as the Super User". When applications consistently bind as the administrative LDAP user to carry out their work, something is probably wrong. The most likely cause is that the value or the functionality of the LDAP security model is not understood. Perhaps the application would now have to use many different credentials instead of just one. LDAP Proxy Auth is briefly introduced as an additional potential approach.

Example 3 discusses the problem of "Repetitive Queries, or the infamous hour-long synchronization". Many times, LDAP applications fetch a list of entities, and then make one LDAP query per entity in a loop. This is often seen in portal servers that try to build a list of users for their internal cache. This is usually seen when the portal server starts up, and in some cases is known to delay the start-up for more than an hour in extreme cases. These problems can typically be avoided by minimizing the queries and using more intelligent LDAP filters. Some examples of those types of loops are given with alternative approaches how this could be done better.

This presentation will focus on general programming concepts, but examples are provided from the Java, C and Perl world.

Felix Gaehtgens was not entirely convinced about X.500 and DAP in the early nineties - however, he got fascinated with and excited about LDAP directories in 1998! Through many engagements with customers he's seen the good, the bad and the very ugly of LDAP deployments. In 2001, he envisioned the future of directory virtualization and co-founded Symlabs. He is currently Symlabs' chief architect for Directory Extender, a LDAP proxy and virtual directory. His responsibilities include management of our flagship DE product, pre-sales efforts and developing strategic channel partnerships. He also helps Symlabs' largest customers solve challenges in directory and identity management deployments.

Mr. Gaehtgens has more than 16 years of high-tech experience. Prior to founding Symlabs, he was an independent consultant and worked with large corporations and public institutions in the United States, Latin America and Europe. His projects included designing, deploying, developing and supporting systems for mobile telephone networks, ISPs, Internet portals, large enterprises and unified messaging systems.

Mr. Gaehtgens' technical articles have appeared in publications including Unix Systems, Unix World, Springer Verlag, and Heise Verlag in English, German and Spanish. He has contributed several articles to GUUG publications in the last two decades.

For ages Samba has supported its user database to be stored in an LDAP directory. This talk will give an overview of how Samba uses LDAP in connection with nss_ldap.

In the past we have had severe perfomance problems, one of the most prominent one was the initial failure when trying to migrate the German Parliament's NT4 domain to a Samba/OpenLDAP based domain. This talk will describe the problems there in detail and what we have done to fix those problems.

Lately Samba has added some features to edit the Posix account database, making it a lot simpler for the admin to set up a completely transparent domain where the admin does not have to be aware that the user database is stored in LDAP. In the talk I will describe how to use this.

From within the Samba user base we see problems in particular with large user and group databases. In particular the NSS interface as Unix applications expect it today is a major bottleneck for the one million user directory. In this talk I will briefly present the problem we see and hopefully trigger some discussion about potential solutions.

As it is always a hot topic at conferences, I'm certainly also open to questions regarding Samba4 and LDAP.

Slides...

Volker Lendecke has a degree in Mathematics from the University of Göttingen. He is member of the Samba Team, his first patches date back to 1994. In 1997 he co-founded the SerNet GmbH in Göttingen.