![The LDAP Protocol Glen Plantz [email_address]](https://image.slidesharecdn.com/theldapprotocolv3-090521161132-phpapp01/85/The-Ldap-Protocol-1-320.jpg)
![BIND/UNBIND/ABANDON Request includes LDAP version, the name the client wants to bind as, authentication type Simple (clear text passwords, anonymous) Kerberos Server responds with a status indication UNBIND: Terminates a protocol session UnbindRequest ::= [APPLICATION 2] NULL ABANDON: MessageID to abandon](https://image.slidesharecdn.com/theldapprotocolv3-090521161132-phpapp01/85/The-Ldap-Protocol-39-320.jpg)
![LDAP URL Format "ldap://" [ hostName [":" portNumber] ] "/" baseDN ["?" attributeList ["?" scope "?" filterString ["?" extensions ] ] ] For example, if a client searches the subtree dc=airius, dc=com for all entries with a surname smith (as in the preceding example), the referral would be returned as the following LDAP URL: ldap://server1.airius.com:389/ou=Engineering, dc=airius, dc=com](https://image.slidesharecdn.com/theldapprotocolv3-090521161132-phpapp01/85/The-Ldap-Protocol-51-320.jpg)
Uploaded byGlen Plantz
The Ldap Protocol
The document provides a comprehensive overview of the Lightweight Directory Access Protocol (LDAP), detailing its purpose, structure, and functionalities. It covers directory information storage, schema, and security, along with various implementations and the protocol's interactions with clients and servers. Additionally, it discusses LDAP's role in e-business architecture, emphasizing its application in access integration and collaborative patterns.
More Related Content
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
The Ldap Protocol
- 1. The LDAP ProtocolGlen Plantz [email_address]
- 2. Agenda Background andMotivation Understanding LDAP Protocol Model Vendors Implementations Directory Middleware Vendors Protocol Details Security Directory Services in Patterns for eBusiness Architecture Discussion
- 3. Background and MotivationCentral Corporate Repository for commonly used information Need in information Functionality Ease-of-Use Administration Clear and consistent organization Integrity Security
- 4. Concept Directory Specializeddatabase that stores information about objects List information about printers Allow user or application to find resources that have the characteristics needed for a task Find a server that can access customer billing information White and yellow pages
- 5. Comparison with relationaldatabase Optimized for read access High volumes of Read and Search request Rare update request No transactions The way information can be accessed LDAP URL
- 6.
- 7. X.500 X.500 standarddirectory
- 8. What is LDAP?Lightweight Directory Access Protocol Used to access and update information in a directory built on the X.500 model Specification defines the content of messages between the client and the server Includes operations to establish and disconnect a session from the server
- 9. LDAP server Gatewayto an X.500 server Stand-Alone
- 10. Understanding LDAP Lightweightalternative to DAP Uses TCP/IP instead of OSI stack Simplifies certain functions and omits others… Uses strings rather than DAP’s ASN.1 notation to represent data
- 11. LDAP v2 (DraftStandard) RFC 1777: LDAP v2 RFC 1778: The String Representation of Standard Attribute Syntaxes RFC 1779: A String Representation of Distinguished Names RFC 1959: An LDAP URL Format RFC 1960: A String Representation of LDAP Search Filters
- 12. Version 2 vsVersion 3 Referrals A server that does not store the requested data can refer the client to another server. Security Extensible authentication using Simple Authentication and Security Layer (SASL) Internationalization UTF-8 support for international characters. Extensibility New object types and operations can be dynamically defined and schema published in a standard manner.
- 13. LDAP Models Information Structure of information stored in an LDAP directory. Naming How information is organized and identified. Functional / Operations Describes what operations can be performed on the information stored in an LDAP directory. Security Describes how the information can be protected from unauthorized access.
- 14. Directory Information TreeData is stored in entries Entries are ordered as tree nodes in the Directory Information Tree (DIT) Every node as 0 to n children Every node except root as 1 parent node
- 15. Directory Information Tree(DIT) DN: cn=Joe Buck,ou=Sales,dc=sun,dc=com
- 16.
- 17. LDAP Information StorageEntries have a " type” specified by it’s “objectClass” Person, Server, Printer etc. Example Entry: InetOrgPerson(cn, sn, ObjectClass) Example Attributes: cn (cis), sn (cis), telephoneNumber (tel), ou (cis), owner (dn), jpegPhoto (bin)
- 18. LDAP Information StorageEach attribute has a type and zero or more values Can define how values behave during searches/directory operations Type: bin, ces, cis, tel, dn etc.
- 19. LDAP Attribute ExamplesUID Userid DC domainComponent STREET StreetAddress C CountryName OU OrganizationalUnitName O OrganizationName ST StateorProvinceName L LocalityName CN CommonName String Attribute Type
- 20. LDAP Naming Anentry has a distinguished name ( DN) DNs consist of sequence of Relative DN Example DN: cn=Joe Buck,ou=Sales,dc=sun,dc=com in its hierarchy level: Relative Distinguished name ( RDN) all RDNs from the root onwards build the Distinguished Name ( DN ) Directory Information Tree (DIT) No two entries in one hierarchy level can have the same RDN Thus no two entries in the whole Directory can have the same RDN Follow geographical or organizational scheme Aliases
- 21. LDAP Naming DNsconsist of sequence of Relative DN cn=John Smith,ou=Austin,o=IBM,c=US Directory Information Tree (DIT) Follow geographical or organizational scheme Aliases
- 22. Directory Information Tree(DIT) DN: cn=Joe Buck,ou=Sales,dc=sun,dc=com
- 23. LDAP Naming Schema Defines what object classes allowed Where they are stored What attributes they have (objectClass) Which attributes are optional (objectClass) Type/syntax of each attribute (objectClass) Querying the schema supported by a server. LDAP schema must be readable by the client
- 24. LDAP Naming Referrals:May not store entire DIT (v3) Referrals objectClass=referral, attribute=ref, value=LDAPurl Implementation differs Referrals/Chaining (vendor) RFC 1777: server chaining is expected.
- 25. OIDs An Entryis an information object The mechanisms for representing the data are objects as well, identified by an OID ( Object Identifier) E.g. : 1.234.567.8.123 OIDs are again represented in a hierarchical tree OIDs are world wide unique
- 26. LDAP Vendors Server:OpenLDAP Oracle Internet Directory Novell eDirectory Sun ONE Directory Server ( was iPlanet Directory Server) IBM Directory Server Microsoft Active Directory Client: Microsoft Outlook & Outlook Express
- 27. Sun ONE DirectoryServer Features Overall fastest LDAP performer Centralized management console SDK (Perl, C, Java) Security (ACL, SSL, SASL) Data Replication Extensible/Plug-ins Referrals
- 28. LDAP Implementations CLibrary API LDAPv2 - RFC 1823 ‘The LDAP API’ LDAPv3 – In Internet Draft stage Java JNDI PerLDAP and Net::LDAP – Accessing from Perl C++ API – Experimental – OpenLDAP.org LDAP v3 uses the UTF-8 encoding of the Unicode character set.
- 29. Directory Middleware VendorsVirtual Directory Vendors Octetstring – Virtual Directory Engine Radiant Logic Meta-Directory Vendors IBM Directory Integrator Maxware Critical Path Meta-Directory Server Identity Management Netegrity - Identity Minder Secure Computing Corporation -Safeword Premier Access Sun ONE - Identity Server
- 30.
- 31. LDAP Functions/Operations AuthenticationBIND/UNBIND ABANDON Query Search Compare entry Update Add an entry Delete an entry (Only Leaf nodes, no aliases) Modify an entry Modify DN/RDN
- 32. Protocol Model Clientsperforming protocol operations against servers Client sends protocol request to server Server performs operation on directory Server returns response (results/errors) Asynchronous Server Behavior Is a CONNECTION-ORIENTED Protocol
- 33. Protocol Elements LDAPMessage(MessageID unique)
- 34. Protocol Elements LDAPResult Errors Truncated DIT RDN sequence is sent noSuchObject aliasProblem invalidDNSyntax isLeaf etc.
- 35. Protocol Element EncodingEncoded for Exchange using BER (Basic Encoding Rules) BER defined in Abstract Syntax Notation One (ASN.1) High Overhead for BER Restrictions imposed to improve perf. Definite form of length encoding only Bit Strings/ Octet Strings and all character string types encoded in primitive form only
- 36. Client and ServerInteraction Client establishes session with server (BIND) Hostname/IP and port number Security User-id/password based authentication Anonymous connection - default access rights Encryption/Kerberos also supported Client performs operations Read/Update/Search Client ends the session (UNBIND) Client can ABANDON the session
- 37.
- 38. Mapping onto TransportUses Connection-oriented, reliable transport TCP LDAPMessage PDU mapped onto TCP byte stream LDAP listener on port 389 Connection Oriented Transport Service (COTS) LDAP PDU is mapped directly onto T-Data
- 39. BIND/UNBIND/ABANDON Request includesLDAP version, the name the client wants to bind as, authentication type Simple (clear text passwords, anonymous) Kerberos Server responds with a status indication UNBIND: Terminates a protocol session UnbindRequest ::= [APPLICATION 2] NULL ABANDON: MessageID to abandon
- 40. Search/Compare Request includes baseObject: an LDAPDN Scope: how many levels to be searched derefAliases: handling of aliases sizeLimit: max number of entries returned timeLimit: max time allowed for search attrsOnly: return attribute types OR values also Filter: cond. to be fulfilled when searching Attributes: List of entry’s attributes to be returned Read and List implemented as searches Compare: similar to search but returns T/F
- 41. ADD/MODIFY/DELETE ADD requestEntry: LDAPDN List of Attributes and values (or sets of values) MODIFY request Used to add, delete, modify attributes Request includes Object: LDAPDN List of modifications (atomic) Add, Delete, Replace DELETE request Object: LDAPDN MODIFY RDN: LDAPDN, newRDN, DEL_FLAG
- 42.
- 43. Issues Authentication IntegrityConfidentiality Authorization Several Authentication mechanisms Bind with password SASL mechanisms Session encryption TLS Access control mechanism On subtree, entry and attribute level Different identifications AuthenticationID, IP address, ... Not yet standardized Security Mechanisms
- 44. LDAP Security Securitybased on the BIND model Clear text ver 1 Kerberos ver 1,2,3 (depr) SASL ver 3 Simple Authentication and Security Layer uses one of many authentication methods Transport Layer Security Based on SSL v3 from Netscape
- 45. LDAP Security NoAuthentication Basic Authentication DN and password provided Clear-text or Base 64 encoded SASL (RFC 2222) Parameters: DN, mechanism, credentials Provides cross protocol authentication calls Encryption can be optionally negotiated ldap_sasl_bind() (ver3 call) Ldap://<ldap_server>/?supportedsaslmechanisms
- 46. LDAP Security LDAPusing SASL using SSL/TLS
- 47. LDAP Security SSL/TLSHandshake
- 48.
- 49.
- 50. Referral Scheme forKnowledge References
- 51. LDAP URL Format"ldap://" [ hostName [":" portNumber] ] "/" baseDN ["?" attributeList ["?" scope "?" filterString ["?" extensions ] ] ] For example, if a client searches the subtree dc=airius, dc=com for all entries with a surname smith (as in the preceding example), the referral would be returned as the following LDAP URL: ldap://server1.airius.com:389/ou=Engineering, dc=airius, dc=com
- 52. LDAP Data InterchangeFormat LDIF RFC 2847 The LDAP Data Interchange Format (LDIF) Technical Specification, G. Good, June 2000 Format for exchanging data Example: dn: cn=Mister X, o=University, c=CE objectclass=top objectclass=person objectclass=organizationalPerson cn=Mister X cn=Xavier Xerxes mail=X@dot.com mail=Mister.X@dot.com telephoneNumber=1234567 dn: cn=next entry, ...
- 53. How Directory Servicesfit into IBM’s Patterns for eBusiness Architecture
- 54.
- 55. Patterns for eBusinessthat depend on Directory Services Collaboration Business Pattern Access Integration Pattern
- 56.
- 57. Directed Collaboration application pattern
- 58. Access Integration PatternsAccess Integration requires services that can include one or more of the following: Device support Presentation Personalization Security and Administration
- 59. Application patterns forAccess Integration
- 60. Web Single Sign-Onapplication pattern
- 61. Web Single Sign-Onrun-time pattern Homogeneous application server
- 62. Combined Runtime patternvariation 1
- 63. Access Integration SingleSign-On and Personalized Delivery application patterns: Product mappings
- 64. Want To KnowMore? www.kingsmountain.com/ldapRoadmap.shtml Another roadmap and tutorial www.openldap.org www.ldapzone.com
Editor's Notes
- #4 Reference –2) ISODE whitepaper – “Why Deploy an Enterprise Directory?” 3) ePresence white paper, “Directory Services” ( Why Directory Services) 4) LDAP Directories Explained, Chap 1 – pages 3-6Today, the key driving force behind general-purpose enterprise directories is for providing a central corporate repository for commonly and widely used information. This includes information about employees of the enterprise for example white pages data (email addresses, phone numbers) and information enabling access to services (printers, computers, buildings). In addition, authentication, encryption and digital signatures are frequently required for secure communications. Directories were designed to support PKI (Public Key Infrastructure) which provides these facilities. Providing a directory using open directory standards enables a wide range of enterprise applications to interface with a single enterprise directory.Directory Services play a key role in the development and support of an enterprise’s e-Business infrastructure. As organizations increase the level of deployment of E2E, B2E, B2C and B2B applications, they are finding that the applications often share similar requirements for:• identity management• security and authentication• access controls• personalization• provisioning• providing common authentication for EAI infrastructures that support integration with supply chain management, CRM, ERP, billing, support and other applicationsFunctionality – Allow Searching, Adding, Modifying, Deleting.Ease-of-Use – No “Heavy Lifting” ( ie OSI … NOT! )AdministrationSimplify changes to customer and user informationClear and consistent organizationPromote greater CONSISTENCY ACROSS APPLICATIONSIntegrityThe assurance that information has not been changed or corrupted by an unauthorized party. Security – Reliable linking of customer and user identity with security credentials
- #5 References – 1) Safari “Understanding and Deploying LDAP…Chapter 1 “Chapter 1. Directory Services Overview” 2) “Revisiting the Hierarchical Data Model”LDAP Directories Explained – Chapter 1, p.13 – “Typical Directory Use”Directories are organized in an object-oriented and hierarchical way. Informationabout a real-world object is stored in the entry that represents this object inthe directory. To mirror the relationships of their respective objects, entries canbe organised in a tree structure.Directory services provide a common schema for what can/must be stored for acertain class of objects and a standard access protocol, which greatly facilitatesinteroperability.• Directories services offer a fine-grained security model. For example, accessrestrictions can be specified for one entry and then inherited by all entries belowthis entry in the directory tree.• Directory services do not support transactions. Instead, they adopt a looseconsistency model. This allows for improved local availability of the servicein a distributed environment.
- #6 References – 1) Understanding and Deploying LDAP Directory Services, Chap.1, section,”What is a Directory” 2) Revisiting the Hierarchical Data Model, section 3 3) LDAP Directories Explained, p. 11, Directories vs. Databases 4) ldap_tut_v2.pdf – only slides, but good outline on this subject world.” Directories have some properties that set them apart from relational databases [68]:• Directories are organised in an object-oriented and hierarchical way. Informationabout a real-world object is stored in the entry that represents this object in the directory. To mirror the relationships of their respective objects, entries can be organised in a tree structure.• Directory services provide a common schema for what can/must be stored for a certain class of objects and a standard access protocol, which greatly facilitates interoperability.• Directories services offer a fine-grained security model. For example, access restrictions can be specified for one entry and then inherited by all entries below this entry in the directory tree.• Directory services do not support transactions. Instead, they adopt a looseconsistency model. This allows for improved local availability of the service in a distributed environment.Read-to-write ratio. Directories typically have a higher read-to-write ratio than databases. Extensibility. Directories are typically more easily extended than databases. It is rare to find a database that allows you to introduce a new, primitive data type with new semantics. Distribution scale. Directories are usually more widely distributed than databases. Data distribution is a fundamental factor in the design of directories. Part of the directory's purpose is to allow data to be distributed across different parts of your network. This capability is aimed at addressing environments where authority and administration must be distributed. Replication scale. Directories are often replicated on a higher scale than databases. As we shall see later, performance is an important directory characteristic. One good way of helping to ensure great performance is to make sure that each user of the directory has a copy of it close by. Performance. Directories usually have very different performance characteristics than databases. A typical large database system might handle hundreds of transactions every second. The aggregate directory performance required by a typical large directory system may be thousands or tens of thousands of queries per second. These queries are usually simpler than the complex transactions handled by databases. Standards. Support for standards is important in directories, less so in databases. In the directory world, because applications from any vendor must be able to use the directory, real interoperable standards are critical.
- #7 References ePresence 1) “Directory Powered Business” 2) Directory Services-Key Building BlockThis slide is meant to give a snapshot of the CONTEXTS in which LDAP is used.Web Single Sign-On (SSO)Web single sign-on allows an employee, customer or business partner to sign on once, using a single password, and access all authorized applications. This dramatically improves the experience of the user. It also greatly reduces IT support costs related to retrieving and resetting passwords. The web single sign-on service relies on directory services to manage and synchronize identity and security information across all of the user’s applications.ProvisioningProvisioning essentially boils down to the concept of using changes to a Directory Service object to signal changes in applications that rely on that data.Provisioning uses business rules and workflow processes to allocate access rights and physical resources to employees, customers and business partners. Later it helps modify and “deprovision” access. Provisioning can be initiated by an administrator, or by a user from a “self-service” interface delivered through a browser. Provisioning applications rely on directory services to identify and manage the resources that are appropriate to each user, and to help apply roles and policies to the provisioning process.Portals and Web-Based ApplicationsA portal provides a user with a single point of entry to all of the applications needed by that user.Portals can address the needs of employees, customers, and supply chain partners for access tocorporate information, transactional systems, external news sources, and collaboration andsupport tools. Portals use directory services to track the applications authorized for each user, tohelp authenticate users, to provide personalized screens and applications, and to “push” corporateinformation to targeted groups.
- #8 Reference – 1) Safari – Understanding and Deploying LDAP Directory Services, Chapter 2, section “General-Purpose, Standards-Based Directories” 2) Understanding X.500 - D W Chadwick – CHAPTER 1 covers history VERY WELLThe Dawn of Standards Directories: X.500Directory Services started as a service to look up phone numbers and email addresses.In the mid-1980s, two separate standards bodies independently started work on directory services that could work across system, corporate, and international boundaries. The first body was the International Telegraph and Telephone Consultative Committee (CCITT) This graphic is an example of what an X.500 “Directory” looks like.Organizes directory entries into a hierarchical namespacePowerful search capabilitiesOften used for interfacing incompatible directory servicesUsed DAP for c/s communicationDAP (App. Layer) requires ENTIRE OSI stack to operateToo heavy for small environments
- #9 Reference – Safari book “Understanding and Deploying LDAP Directory Services “Beginning of Chapter 3At its core, LDAP is a standard, extensible directory access protocol—a common language that LDAP clients and servers use to communicate with each other. Standardization of the protocol has the benefit that client and server software from different vendors can interoperate. When you buy an LDAP-enabled program, you can expect that it will work with any standards- compatible LDAP server. This has many advantages, but we'll discuss those later in this chapter.LDAP is a \"lightweight\" protocol, which means that it is efficient, straight- forward, and easy to implement, while still being highly functional. Contrast this with a \"heavyweight\" protocol, such as the X.500 Directory Access Protocol (DAP). X.500 DAP uses complex encoding methods and requires use of the OSI network protocol stack—a networking system that has failed to gain wide acceptance.LDAP, on the other hand, uses a simplified set of encoding methods and runs directly on top of TCP/IP. Every major desktop and server computing platform currently available (Microsoft Windows, DOS, UNIX, and the Apple Macintosh) either ships with a TCP/IP implementation or can be easily equipped with one. OSI networking, on the other hand, is not universally available, and it is almost always an extra-cost option. LDAP, by virtue of its light weight, removes significant barriers to implementation and deployment.. Lightweight alternative to DAPUses TCP/IP instead of OSI stackSimplifies certain functions and omits others…Uses strings rather than DAP’s ASN.1 notation to represent data
- #10 References 1) Manning eBook, Chapter 1, sections 1.1, 1.2LDAP servers started out as a GATEWAY.Two general types of directory server software implement the LDAP standards:• LDAP gateway servers• Stand-alone LDAP server LDAP gateway servers translate between LDAP and some other native network protocol or application program interface (API) to provide access to directory information that is more directly available via other means. Stand-alone LDAP servers focus exclusively on LDAP as their only access mechanism; their proprietary internal data stores are tuned for LDAP access. These are typically what people mean when they use the words LDAP server. Instead of being tied to a local data store, One example is the original use of LDAP: to gateway to other directory services supporting the X.500 standards. Another more modern example of such an LDAPgateway is a server that provides LDAP access to information residing in Oracledatabase tables.
- #11 Reference: 1) isode.com article “LDAP and X.500” 2) LDAP Programming with Java, Chap2, “A Brief History of Electronic Directories”Before looking further at the role of LDAP in relationship to X.500, it is useful to consider why LDAP is 'simple', relative to X.500: Simple protocol encoding. While the LDAP PDUs are based on those from X.500, elements of the protocol have been modified to produce a protocol that is significantly simpler. Names and attributes use text encoding. Names and attributes are pervasive in the protocol. In X.500, these have a complex ASN.1 encoding, whereas in LDAP they are given a simple string encoding. This is particularly helpful for applications that do not need to handle the detailed structure of names or attributes. Mapping directly onto TCP/IP. LDAP maps directly onto TCP/IP (the Internet transport layer), and removes the need for a non-trivial amount of OSI protocol. Simple API. The University of Michigan implementation has set a de facto API standard, published as RFC 1823. This is arguably the most important benefit, as it enables easy implementation of directory enabled applications. The X/Open XDS interface, which is the preferred API onto X.500, is much more complex. LDAP relies on X.500 for the service definition and distributed operations. Because LDAP is defined as an access protocol to X.500 and not as a complete directory service, it is possible to specify LDAP very concisely. The detailed service definitions, while often intuitive from the protocol, are formally specified in X.500. Where the directory service is provided by more than one Directory Server, the procedures for doing this are not defined by LDAP. The original LDAP was very clearly a lightweight access protocol to an X.500 directory. It is important to understand this clearly, when looking at the issues of providing a large scale directory service.
- #12 In 1991, after a few false starts with other potential standards, LDAP was broughtforth as a lightweight means for accessing the DAP-enabled directories of the X.500world. The first set of standards, LDAPv2, were eventually defined and accepted by the Internet Engineering Task Force (IETF), an important standards body responsible for many important Internet standards, as RFCs 1777 and 1778.The University of Michigan, developed the reference implementation of LDAP ( Version 1)
- #13 References 1) ISODE whitepaper – “LDAP Version 3” 2) internet draft Zeilenga - LDAP Version DifferencesRefferrals The directory information tree can be distributed across multiple servers through the X.500 concept of the naming context, a contiguous tree of entries mastered by a single server. If an LDAPv3 server receives a request which affects an entry outside of the naming contexts it holds, then it can return to the client a referral, containing the URLs of servers which are more likely to hold that naming context.The client can control whether the server returns referrals by providing a list of the protocols it supports for referral, such as 'ldap' or 'X.500', and sets service controls for the server which control how the server makes use of referrals.Earlier versions of LDAP did not permit servers to return referrals. This meant that servers were required to be able to contact other servers if necessary, which would often require significant additional network processing resources on servers. Security…..Management Since with referrals clients may be contacting arbitrary servers in the Internet, LDAPv3 servers are required to provide additional management information. The client can obtain from the server: A list of the naming contexts it maintains, The URLs of alternative servers to contact in case this server is later unreachable. ; The identifiers of any supported extensions which this server supports. The electronic mail address of the server's administrator. The client can also retrieve from each entry the name of the client which last modified the entry, and the time when it was last modified.A client when following a referral indicates to the referred-to server the URL of the referring server, so that if a server has incorrect knowledge about the distribution of directory information, this problem can more quickly be detected.In LDAPv2, the complete list of object classes and attributes permitted to be carried in protocol was fixed in the specification, and there was no mechanism for a client to discover if a server was capable of handling additional attributes. LDAPv3 servers are required to support the X.500 subschema subentry, in which they publish all their supported object classes and attributes. Thus organizations can define and use their own attributes in servers, and there is a mechanism for clients to discover the definitions of these attributes.InternationalizationAs LDAP version 2 was based on the attribute definitions in X.500 (1988), the only supported character sets were ASCII and T.61 (a western European character set). X.500 (1993) also permits the Unicode character set to be used, which has been designed to allow for all natural language scripts to be represented, including those of Asian languages. In LDAPv3 all string values and distinguished names are written in a UTF-8 encoding of the Unicode character set. UTF-8 encodes a character into a variable number of bytes, and the advantages over double-byte or four-byte character encodings is that its representation is more space efficient, and that printable ASCII characters have the same representation in UTF-8.There is also a framework added to LDAPv3, which allows for attributes to be tagged with a language. This mechanism is intended to allow future extensions to support multiple languages in a single directory.ExtensibilityLDAPv3 provides a framework for bilaterally defined operations, which could be optionally supported by clients or servers. This will be used as a framework for future extensions of LDAP and is also useful for certain deployments which require additional features be carried in LDAP, for example X.500 signed operations and results.
- #14 Reference - Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”Information Model • How is information stored in LDAP? What is an information model? Why is it important, and how does it simplify application development?• Where is LDAP’s information model defined? • What is the LDAP schema? What makes up the schema?• What is an entry? How do entries compare to rows in a database? How does the schema affect entries?• What are object classes? What are attribute types? How are object classes in LDAP different from classes in a programming language? What is inheritance, and how does it affect an object class’s definition?• How are attributes different from fields in a database? How are attributes different from variables in a programming language?Naming • What is a namespace? What does LDAP’s namespace look like? How is a hierarchical tree different than a flat structure? • What is a directory tree, and why is it sometimes called a DIT? How can the tree be used to relate data? Distinguish it? • What is a distinguished name? What components does it consist of? How is it written? • What is the advantage of a flat tree over a deep tree? Why is a deep tree sometimes more important? • What factors should be used to determine the relative distinguished name (RDN)? • Should distinguished names be meaningful or unchanging unique identifiers? • What is a Globally/Universally Unique ID (GUID/UUID)? When are these IDs useful in LDAP? How are they generated?Functions/Operations • What makes up the LDAP search criteria? When are they used? • What are the search base and scope? How do they affect the entries returned? • How is the search filter constructed? What common pitfalls do you need toavoid with search filters? • What search criteria offer the best performance? Worst? • What similarities and differences exist between LDAP searches and SQL queries?Security• What is security, and how does it relate to directories? • How can directories most effectively enable different types of security? • How can an LDAP server be used for authentication? • What are the limitations of private keys when used for authentication? How can certificates help? • How can certificates be generated and stored in the directory?• What is necessary to enable session encryption in JNDI?
- #15 Reference – 1) Sample chapter from Tenanbaum’s Distributed Systems, 4.1 “Naming Entities” 2) Sun BluePrints – “Demystifying the LDAP Directory Information Tree”First we will talk about how information in an LDAP Server is STORED, ie the “Information Model”A directory entry in LDAP is made up of a collection of Entries, which have (attribute, value) pairs, where each attribute has an associated type. The Entries are organized in a hierarchy, which is referred to as a Directory Information Tree (DIT). A DIT essentially forms the naming graph of an X.500 directory service in which each node represents a directory entry. In addition, a node may also act as a directory in the traditional sense, in that there may be several children for which the node acts as parent.DIT functions The DIT has multiple functions:• The DIT allows entry names to be unique across enterprise boundaries. Each enterprise has names within the DIT that fall under their own place in the hierarchy.• The DIT can be distributed. Most directory servers allow different levels within the DIT to be placed on different servers (see figure 3.2). In many organizations where data ownership is distributed, this function allows the people closer to the data to manage their portion of a larger directory more easily.This approach is similar to how IT organizations around the world split the management of DNS across seemingly infinite groups of people. Such management scalability is often one of the most attractive aspects of LDAP once properly enabled applications move beyond the development phase to the deployment phase; at that point, scalable management is often an important factor in how fast an application can be rolled out.• The DIT facilitates security. Security rules in most directory servers are usually relative to certain branches of the tree. In the latest Internet Drafts related to access control, an access control rule can apply to a particular entry, or to that entry plus all the entries below it in the hierarchy (see figure 3.3). This approach is similar to how access control rules work in most other commercialLDAP products.
- #16 Reference – 1) See sample chapter from Tenanbaum’s Distributed Systems, 4.1 “Naming Entities” 2) Manning eBook, pages 79-80, section “What is a Namespace?” 3) Example, use Safari – LDAP Programming with Java, Chapter 12. Modeling Relationships, “Mirroring an Organizational Structure “, … excellent example “This is what a directory tree looks like”
- #17 Reference - Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”******* GIVE EXAMPLE ******The basic unit of information in the directory is the entry, a collection of information about an object. Often, the information in an entry describes some real-world object such as a person, but this is not required by the model. If you look at a typical directory, you'll find thousands of entries that correspond to people, departments, servers, printers, and other real-world objects in the organization served by the directory Entry – Similar to an object, but has NO METHODSAn entry is composed of a set of attributes, each of which describes one particular trait of the object. Each attribute has a type and one or more values. The type describes the kind of information contained in the attribute, and the value contains the actual data objectclass ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURALMUST ouMAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $x121Address $ registeredAddress $ destinationIndicator $preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $telephoneNumber $ internationaliSDNNumber $facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) SUP name )attributetype ( 2.5.4.41 NAME 'name'EQUALITY caseIgnoreMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
- #18 Reference - Understanding and Deploying LDAP Directory Services, Chapter 3, The LDAP Models”Object classes in LDAP tell you which attributes are required and allowed to be in a particular LDAP entry. LDAP entries are placed into an object class via the use of a special attribute type called objectClass.The objectClass attribute simply gives you information about the type of entry being stored in the directory. This example tells you that the entry belongs to three object classes: top, person, and organizationalPerson. In turn, knowing the object class of an entry helps you figure out what kinds of attributes you will find in it.Like attribute types, object classes include the following components:• Name• OIDs• InheritanceIn addition to those components, an object class includes information that defines the allowable contents of entries that use that object class. Such information includes:• Class type• List of required attribute types• List of allowed attribute typesObject class namesObject class names in LDAP are case-insensitive strings containing only letters, numbers, dashes (-), and semicolons (;). Traditionally, names have included only letters and numbers.objectclass( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'DESC 'RFC2798: Internet Organizational Person' SUP organizationalPersonSTRUCTURALMAY ( audio $ businessCategory $ carLicense $ departmentNumber $displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ))
- #19 Reference – 1) LDAP Directories Explained – Chapter 4 – LDAP Schema 2)Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”Entries are made up of smaller units of data called attributes. Like fields in a database, these attributes contain key/value pairs that describe a particular entry. The key portion of the attribute is called the attribute type, and the value or values are called attribute values. Attribute types are the building blocks of LDAP entries.Attribute type definitions include the following components: • Name • Object IDentifiers (OIDs) • Syntax • Matching rules • InheritanceAttribute Syntaxes Syntaxes define how attribute values are compared during a search or compare operation. LDAP allows specifying unique rules for each type of search and sort: equality, substring, and ordering. These rules are defined as additional qualifiers in the attribute definition, besides the syntax qualifier. However, Netscape Directory Server and many other LDAP servers ignore the additional qualifiers and just use the syntax qualifier.In the table of attribute types, the following shorthand is used for syntax types:Shorthand OID Descriptionbin 1.3.6.1.4.1.1466.115.121.1.5 A binary valueces 1.3.6.1.4.1.1466.115.121.1.26IA5 String—case-sensitive stringcis 1.3.6.1.4.1.1466.115.121.1.15 Directory StringUTF-8, case-insensitive stringdn 1.3.6.1.4.1.1466.115.121.1.12A distinguished nameint 1.3.6.1.4.1.1466.115.121.1.27Integertel1.3.6.1.4.1.1466.115.121.1.50Telephone numberStoring Binary DataThe LDAP SDK supports storing of binary data into attributes. This feature is useful for maintaining information that cannot be represented in a string format. Binary storage can be used to maintain photographs of people in the directory, thereby providing security personnel with up-to-date and accurate pictures of personnel, or to customize an online phone book entry. Another common use of binary data in LDAP directories is storage of digital certificates.
- #20 Reference - Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”These are examples of commonly used attributes. The “cn” attribute is the most commonly used attribute.Example from “core.schema”attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )Both “cn” and “commonName” can be used. If an LDAP search is done, the first name “cn” will be returned. This first name is called the “conanical” name for this attribute.
- #21 Reference – Manning LDAP ebook, sec.3.2 “Specifying Distinguished Names”“Now we will discuss how Entries in LDAP are ‘Referred to’ You “refer” to an entry using the entries “Name”The fully qualified name of an LDAP entry is called its distinguished name or DN. This distinguished name can be broken into two pieces:• The RDN -• The baseEvery LDAP operation that changes the LDAP directory uses the full distinguished name to identify the entry to affect. Similarly, operations that authenticate the user to the directory also require specification of the full distinguished name. Search operations may involve all or part of the distinguished name.The Entries are arrange in an “Inverted Tree Structure”, making up a “hierarchy” ( show inverted tree). LDAP is not the only example of a Hierarchical Organization of data. The UNIX file system is another example of a hierarchical organization of data.Hierarchical namespacesEntry names in LDAP are hierarchical: they are organized in a tree structure. Each entry is given a name relative to its position in the tree. This relative name need only be unique among entries that share the same parent entry. This is different from a flat namespace, in which the name of an entity is unrelated to any other entities in the namespace. In the directory world, this type of trees is usually referred to as the directory information tree (DIT).Geographic trees There are still a few places where division of the tree must happen for reasons that are technical in nature. One such reason is geography: links between continents, countries, or even relatively small distances may not always be desired.Organization-based trees Many people tasked for the first time to create an organization-based directory create a hierarchy that models the organizations in an organizational chart.Alias entries in the LDAP directory allow one entry to point to another one, which means you can devise structures that are not strictly hierarchical. Alias entries perform a function like symbolic links in the UNIX file system or shortcuts in the Windows 95/NT file system.
- #22 Reference – 1) Manning eBook – Chapter 3 – “LDAP NameSpace” 2) Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”The Entries are arrange in an “Inverted Tree Structure”, making up a “hierarchy” ( show inverted tree). LDAP is not the only example of a Hierarchical Organization of data. The UNIX file system is another example of a hierarchical organization of data.Hierarchical namespacesEntry names in LDAP are hierarchical: they are organized in a tree structure. Each entry is given a name relative to its position in the tree. This relative name need only be unique among entries that share the same parent entry. This is different from a flat namespace, in which the name of an entity is unrelated to any other entities in the namespace. In the directory world, this type of trees is usually referred to as the directory information tree (DIT).Geographic trees There are still a few places where division of the tree must happen for reasons that are technical in nature. One such reason is geography: links between continents, countries, or even relatively small distances may not always be desired.Organization-based trees Many people tasked for the first time to create an organization-based directory create a hierarchy that models the organizations in an organizational chart.Alias entries in the LDAP directory allow one entry to point to another one, which means you can devise structures that are not strictly hierarchical. Alias entries perform a function like symbolic links in the UNIX file system or shortcuts in the Windows 95/NT file system.
- #23 Reference – 1) See sample chapter from Tenanbaum’s Distributed Systems, 4.1 “Naming Entities” 2) Manning eBook, pages 79-80, section “What is a Namespace?” 3) Example, use Safari – LDAP Programming with Java, Chapter 12. Modeling Relationships, “Mirroring an Organizational Structure “, … excellent example “Here we SEE AGAIN the picture of the Directory Information Tree” ….
- #24 Reference - Understanding and Deploying LDAP Directory Services, Chapter 3, “The LDAP Models”The definitions of attribute types and object classes together make up the schema of the directory. These two combined specify what types of ENTRYS can be in the directory. There is a “Default Schema” for an LDAP server – There is a minimum set of schema objects required by the LDAP standard ( in openLdap this is specified in the “core.schema” fileA directory schema is a set of rules that determines what can be stored in a directory service and how directory servers and clients should treat information during directory operations such as a search. Before a directory server stores a new or modified entry, it checks the entry's contents against the schema rules. Whenever directory clients or servers compare two attribute values, they consult the schema to determine what comparison algorithm to use.The Default Schema can be extendedQuerying the schema Two new LDAPv3 features: the subschemaSubentry and the rootDSE objects. Both of these objects allow clients to find out information about a previously unknown directory server. The SubSchemaSubentry attribute specifies the base search suffix for querying the schema supported by the server. This means that clients can verify that the server supports a given matching rule, attribute type, or object class prior to performing an operation that depends on a certain characteristic Clients locate schema by reading the values of the subschemaSubentry operational attribute that is located in an LDAPv3 server's root DSE (directory server–specific entry) or by reading the same attribute from any directory entry. Values of the subschemaSubentry attribute are LDAP DNs that point to entries that belong to the subschema object class. Such entries are called subschema entries. In the Netscape Directory Server, for example, the global set of schema for the server can be found in the subschema entry named cn=schema.The subschema object class allows these seven attribute types to be present:attributeTypes objectClasses matchingRules matchingRuleUse dITStructureRules nameForms ditContentRules
- #25 Reference - Understanding and Deploying LDAP Directory Services, Chapter 9, “Topology Design”, section “Authentication in a Distributed Directory”“Directories can be DISTRIBUTED”A directory that resides on more than one server is a distributed directory. When you carve a single directory into manageable chunks and assign them to separate servers, you are partitioning the directory A referral is a piece of information returned by an LDAP server that indicates to the client that other servers need to be contacted to fulfill the request. The client then typically contacts the other servers, resubmits the original request, and presents the results to the user.The information in an LDAP referral is in the format of an LDAP uniform resource locator (URL), as defined in RFC 2255. A referral gives the following information:The host name of the server to contact.The port number of the server.The base DN (if processing a search operation) or target DN (if processing an add, delete, compare, or moddn operation). This part is optional; if absent, the client should use the same base DN it used when performing the operation that resulted in the referral.
- #26 Reference – LDAP Directories Explained, p, 131-132An OID is a string of dotted numbers that uniquely identifies items such as attributes, syntaxes, object classes, and extended controls. OIDs are allocated by the Internet Assigned Numbers Authority (IANA). The allocation of enterprise numbers by IANA is similar to the central distribution of IP address blocks; once you have been assigned an enterprise number by the IANA, you can create your own OIDs underneath that number. Unlike the IP address space, there is no limit to the number of OIDs you can create because there's no limit to the length of an OID. For example, assume that you were issued the enterprise number 55555. Therefore, all OIDs belonging to your branch of the OID tree would begin with 1.3.6.1.4.1.55555. How this subtree is divided is at your discretion. OID assignments must be unique worldwide. If you ever need to make custom schema files for your directory (a common practice), go to http://www.iana.org/cgi-bin/enterprise.pl and request a private enterprise number ---------------------------The OID is a special number designed to uniquely identify some object,. Object classes, syntaxes, and matching rules use them.An OID is an arbitrarily long string of integers separated by periods. OIDs uniquely identify each and every LDAP objectClass and attributeType. Since OIDs must be unique, developers must ensure that their Object Identifiers do not overlap or collide. To solve this problem, some companies ask the IANA to assign an offical OID prefix. The Internet Assigned Numbers Authority (IANA) gives out OIDs to any organization that asks. IANA calls the OIDs enterprise numbers .A form for obtaining an OID from IANA can be accessed on the Web at http://www.isi.edu/cgi-bin/ iana/enterprise.pl . <number>
- #27 References – 1) Directory Landscape 2003 – Burton Group; 2) “LDAPReport” on for evaluations of vendors; 3) “LDAP Directories Explained”, Chapters on OpenLdap, MS Active Directory, and Directory Server; 4) C:\\LDAP\\Directory Server Vendors.htmOpenLDAP – is a popular, open source LDAPv3-compliant server. OpenLDAP is attractive for several reasons.The OpenLDAP source code is available for download from http://www.openldap.org/ under the OpenLDAP Public License. Source code can provide a great deal of information to supplement existing (or absent) documentation.OpenLDAP 2 is compliant with the core LDAPv3 specifications.OpenLDAP is available for multiple platforms, including Linux, Solaris, Mac OS 10.2, and Windows (in its various incarnations)Oracle Internet Directory Oracle Internet Directory (OID) is a fully compliant LDAP v3 directory service. Oracle targets OID for large telecommunications carriers and for enterprises that use Oracle applications. In support of those market segments, Oracle focuses on directory scalability and integration with Oracle products. For scalability, OID relies on the robustness of the Oracle database (8i and 9i), making use of its replication, backup, restore, and clustering features. The directory also uses server indexes to provide scalable search models. Although the directory uses Oracle’s database technologyas its underlying data store, OID allows access to the data only through LDAP. For security reasons, programmers cannot use SQL, ODBC, and JDBC to access the database directly.Novell eDirectory; Novell has positioned itself to compete aggressively with Sun for identity management infrastructure. In 2002, Novell has reaped the rewards of its strategy. eDirectory is now on par with Sun ONE Directory Server with respect to LDAP compliance and performance. It also includes compatible support for dynamic groups and dynamic access control. Some of eDirectory’s features, such as multi-master replication and directory management, even surpass those of Sun ONE Directory Server.Sun ONE Directory Server; Sun has had a pivotal role in evangelizing and defining directory services and building out. solutions that leverage a directory infrastructure through the transition of Netscape to iPlanet to Sun ONE. Sun’s latest release, Sun ONE Directory Server 5.1, delivers additional features and performance improvements, with dual-master replication as the most significant improvement. Not only does Sun have a respectable e-business directory, but it also provides the necessary developer tools and integration components to build a strong directoryenabled e-business solution. In addition to its market presence within e-business solutions, Sun has a firm hold on the e-business directory market.IBM Directory Server; In the last 18 months, IBM has produced two major revisions of its directory server. Now in its 4.1 release, IBM plans to release version 5.1 in Q1 2003. The 5.1 release marks the maturation of the directory product, enabling broader use in the enterprise. IBM Directory Server is available on AIX, Windows, Linux (Intel and OS390 – Red Hat, Turbo, and SuSE), Solaris, HPUX, and soon on OS/400. The directory is available free of charge from IBM’s website. IBM Directory Server 5.1 includes several performance improvements such as database optimization and code path improvements for SMP scalability. The 5.1 release also improves on 4.1’s multi-master replication features by offering transitive (or “tiered”) replication as well as a browser-based user interface for managing directory topology.Active Directory; Microsoft Active Directory is a strong directory product from a dominant vendor. As such, the product will enjoy significant market share and developer adoption. The following factors contribute to the success of Active Directory:! Windows platform integration: Active Directory is the only directory capable of managing Windows servers, meaning that every enterprise will eventually use it. Active Directory carries with it an air of inevitability as Microsoft distributes theproduct through the platform upgrade cycle.! Acquisition costs: For enterprise deployments, Active Directory access is included as part of the client access license (CAL), which in turn, is required for most Windows server-based deployments (making Active Directory free of charge for most enterprises). For e-business deployments, Microsoft offers unlimited non-employee usage for $1,999 through its Internet Connector Option licensing program.<number>
- #28 Reference – LDAP Directories Explained, Chapter 8Originally produced as Netscape Directory Server – Sun-Netscape alliance resulted in renaming to iPlanet Directory Server.The Sun product became the Sun ONE Directory ServerBoth iPlanet and Innosoft products rated at #1 and #2 in nearly all performance tests. Many of the other products OpenLDAP, eDirectory, Active Directory, etc., did not even come close. You can see some test results at: http://www.nwfusion.com/reviews/2000/0515rev2.htmlCentralized Management ConsoleiPlanet Console provides a GUI-based interface for the administration of users and groups and for editing ACI statements. An HTML interface is also available. These tools are alternatives to command-line administration.SDK Software Development Kits for the LDAP API in C and Java are provided, and a Perl version is available from http://www.mozilla.org .Security Directory Server has the most access control factors of any LDAP product. Dynamic groups and values are features that reduce management costs, and other products don’t have them.Data ReplicationAlthough we are not using it the way at the moment, it is possible to manager the master and all replica at the same time using the startconsole management utility. However that means all your configuration information eggs are in one basket. Lose it and you’ve lost everything. I wasn’t too confident that we should start out doing it that way.Plug-ins give you the ability to extend the Directory. You can intercept transaction at several points along the way and make additional decisions concerning what to do with the data. That works both when storing/updating the directory as well as when retrieving the information. We are considering writing a couple of plugin. One to verify/validate mailalternateaddress and another to provide more secure password changes.
- #29 References; 1) rfc1823 “The LDAP Application Program Interface”; 1) openldap.org MANUAL page on “Libraries”; 2) Safari book “LDAP Programming with Java “3) Manning eBook, Chapter 11 “Accessing LDAP directories with JNDI”;4) Javaworld.com series on JNDIThe original LDAP distribution from the University of Michigan (often referred to as the U-M LDAP release included a C programming library and several sample client programs built on this library. In addition the various implementations of the C API, other APIs are available; 1) Netscape has developed an LDAPv2 and LDAPv3 Java API that, like the C API, has a close mapping onto the LDAP protocol. 2) JavaSoft has developed the proprietary Java Naming and Directory Interface (JNDI). This API/SDK defines a common interface for accessing a number of different directory systems from a Java application or applet. Additional types of directory systems and protocols can be supported by developing additional service provider interfaces (SPIs) for JNDI. This allows a JNDI client to access a number of distinct directory services, such as NIS, DNS, LDAP, NDS, or X.500.3) Microsoft also has a proprietary, object-oriented SDK, called ADSI, for accessing multiple directory systems. ADSI APIs are available for Visual Basic, C, and C++. 4) Perl fans can use PerLDAP, available from http://www.mozilla.org .
- #30 Reference – Manning eBook –section 1.7 Directory IntegrationDirectories are being used for data integration. This has spawned vendors that provide technology to integrate various legacy data stores. There are 2 basic ways this is done; via Virtual Directories and via Meta-Directories.INTEGRATION AND FEDERATION VIA VIRTUAL DIRECTORY TECHNOLOGYUsually, metadirectories involve the creation of a new, physical directory, the contents of which are based on an aggregation of multiple information sources. One emerging alternative to metadirectory technology is virtual directory technology, sometimes called directory federation technology. This technology attempts to provide real-time directory access to other types of data stores, such as relational databases and memory- based application components. To visualize this process a bit more easily, think of the virtual directory as a kind of proxy server: the application speaks LDAP to the virtual directory software, and the virtual directory software grabs the data directly from the legacy data store by speaking its native tongue.Integration via metadirectories In the past few years, a new breed of applications called metadirectories has come to market to remove some of the burden associated with directory integration. Although it may sound like yet another directory, a metadirectory is really a sophisticated directory integration toolkit. You can use metadirectories to connect and join information between data sources, including directories, databases, and files. The connection process usually involves identifying changes in each data source. Such a connection may be real-time monitoring of changes using a direct access method into the connected data store, an occasional scan of a file-based list of changes, or a review of a full export from the connected data store.Another type of middleware using Directories is for “Identity Management”The Directory as an Authentication Source Using the Directory as an authentication source makes great sense since most directories were designed with security in mind. Extremely granular, robust security mechanisms are available, allowing security down to the attribute level. Many Directory-enabled applications are available to extend directory security mechanisms to include a wide variety of authentication mechanisms, including PKI, biometrics, tokens, and other advanced forms of authentication. Many portal deployments include a security framework that leverages a directory. Products such as Netegrity SiteMinder or Oblix Netpoint take advantage of the directory’s security framework to allow multiple grades of authentication as well as distributed management and application authorization. Databases are not, by default, as flexible with security. Most databases offer column-level security, but the advanced security solutions available with directories are far more flexible and granular.
- #32 References – LDAP Directories Explained. – LDAP Operations – starting page 85There are 10 operations that LDAP defines.The bind operation is how a client authenticates itself to the directory. It does so by providing a distinguished name and a set of credentials. Binding provides an AUTHORIZATION CONTEXT for allowing or denying subsequent operations.The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated.The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation.Interrogation OperationsThe Search Operation allows a client to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately below a particular entry, or a whole subtree of entries.The Compare Operation allows a client to compare an assertion provided with an entry in the directory. Parameters of the Compare Request are:- entry: the name of the entry to be compared with.ava: the assertion with which an attribute in the entry is to be compared.Update OperationsThe Add Operation allows a client to request the addition of an entry into the directory.The Delete Operation allows a client to request the removal of an entry from the directory. The Delete Request consists of the Distinguished Name of the entry to be deleted.The Modify Operation allows a client to request that a modification of an entry be performed on its behalf by a server.The Modify DN Operation allows a client to change the leftmost (least significant) component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory.Extended Operation An extension mechanism has been added in this version of LDAP, in order to allow additional operations to be defined for services not available elsewhere in this protocol, for instance digitally signed operations and results.
- #33 Reference – RFC 2251, section3.1. Protocol ModelThe general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the directory. Upon completion of the operation(s), the server returns a response containing any results or errors to the requesting client.In keeping with the goal of easing the costs associated with use of the directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of using the directory.Note that although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behavior on the part of either clients or servers. Requests and responses for multiple operations may be exchanged between a client and server in any order, provided the client eventually receives a response for every request that requires one.In LDAP versions 1 and 2, no provision was made for protocol servers returning referrals to clients. However, for improved performance and distribution this version of the protocol permits servers to return to clients referrals to other servers. This allows servers to offload the work of contacting other servers to progress operations.Note that the core protocol operations defined in this document can be mapped to a strict subset of the X.500(1997) directory abstract service, so it can be cleanly provided by the DAP. However there isnot a one-to-one mapping between LDAP protocol operations and DAP operations: server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests.
- #34 References – 1) LDAP System Administration – Chap. 4 – starting on Page 83 “LDAP Protocol”This slide shows the “Syntax” of the message a client sends to the LDAP Server.For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined here. The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges.
- #35 Reference – RFC 2251, section 4.1.1 “Message Envelope”This slide shows the “Syntax” of the message a Server sends to the LDAP ClientThe LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. In response to various requests servers will return responses containing fields of type LDAPResult to indicate the final status of a protocol operation request.All the result codes with the exception of success, compareFalse and compareTrue are to be treated as meaning the operation could not be completed in its entirety.
- #36 LDAP uses a simplified version of the Basic Encoding Rules (BER). BER is a set of rules for encoding various data types, such as integers and strings, in a system-independent fashion. It also defines ways of combining these primitive data types into useful structures such as sets and sequences. The simplified BER that LDAP uses is often referred to as lightweight BER (LBER). LBER does away with many of the more esoteric data types that BER can represent, and instead it represents most items as simple strings.THE POINT IS - Because LDAP is not a simple text-based protocol like HTTP, you can't simply telnet to the LDAP port on your server and start typing commands. The LDAP protocol primitives are not simple strings, so it's difficult, if not impossible, to converse with an LDAP server by typing at it. If you are familiar with text-based Internet protocols such as POP, IMAP, and SMTP, this may seem like an unfortunate limitation. On the other hand, DNS, a very successful distributed system, uses a protocol that has nontextual protocol primitives. The presence of universal implementations of client libraries for both DNS and LDAP makes this limitation less problematic.( LDAP Directories Explained) “LDAP uses BER encoding, specifically a simplified subset of BER. ASN.1 messages are placed in a format it calls ‘octet strings’. Octet strings are arbitrarily longs strings of 8-byte data. So an Octet Strings length should always have a factor of 8”
- #37 References – 1) downloaded web page “LDAP Operations”2) LDAP Directories Explained. – LDAP Operations – starting page 85From Safari “Understanding and Deploying LDAP Directory Services, Chap3, An Introduction to LDAPThe LDAP Authentication and Control OperationsThere are two LDAP authentication operations, bind and unbind, and one control operation, abandon.The bind operation is how a client authenticates itself to the directory. It does so by providing a distinguished name and a set of credentials. The server checks whether the credentials are correct for the given DN and, if they are, notes that the client is authenticated as long as the connection remains open or until the client re-authenticates. The server can grant privileges to the client based on its identity.There are several different types of bind methods. In a simplebind, the client presents a DN and a password in cleartext to the LDAP server. The server verifies that the password matches the password value stored in the userpassword attribute of the entry and, if so, returns a success code to the client.The simple bind does send the password over the network to the server in the clear. However, you can protect against eavesdroppers intercepting passwords by encrypting the connections using secure sockets layer (SSL) or TLS, which are discussed in the next section. In the future, LDAPv3 will include a digest-based authentication method that does not require that a cleartext password be sent to the server.LDAPv3 also includes a new type of bind operation, the SASL bind. SASL is an extensible, protocol-independent framework for performing authentication and negotiation of security parameters. With SASL, the client specifies the type of authentication protocol it wants to use. If the server supports the authentication protocol, the client and server perform the agreed-upon authentication protocol.For example, the client could specify that it wants to authenticate using the Kerberos protocol . If the server knows how to speak the Kerberos protocol, it indicates this to the client that sends a service ticket for the LDAP service. The server verifies the service ticket and returns a mutual authentication token to the client. Whenever the Kerberos authentication completes, the SASL bind is complete and the server returns a success code to the client. SASL can also support multistep authentication protocols such as S/KEY.Incorporation of SASL into LDAPv3 means that new authentication methods, such as smart cards or biometric authentication, can be easily implemented for LDAP without requiring a revision of the protocol.The second authentication operation is the unbind operation. The unbind operation has no parameters. When a client issues an unbind operation, the server discards any authentication information it has associated with the client's connection, terminates any outstanding LDAP operations, and disconnects from the client, thus closing the TCP connection.The abandon operation has a single parameter: the message ID of the LDAP operation to abandon. The client issues an abandon operation when it is no longer interested in obtaining the results of a previously initiated operation. Upon receiving an abandon request, the server terminates processing of the operation that corresponds to the message ID. The abandon request, typically used by GUI clients, is sent when the user cancels a long-running search request.Note that it's possible for the abandon request (coming from the client) and the results of the abandoned operation (going to the client) to pass each other in flight. The client needs to be prepared to receive (and discard) results from operations it has abandoned but the server sent anyway. If you are using an LDAP SDK, however, you don't need to worry about this; the SDK takes care of
- #38 This slide is meant to graphically reinforce the idea of the protocol being a “request and response” type. References the same as last slide… for exampleFrom Safari “Understanding and Deploying LDAP Directory Services, Chap3, An Introduction to LDAPThe LDAP Authentication and Control OperationsThere are two LDAP authentication operations, bind and unbind, and one control operation, abandon.The bind operation is how a client authenticates itself to the directory. It does so by providing a distinguished name and a set of credentials. The server checks whether the credentials are correct for the given DN and, if they are, notes that the client is authenticated as long as the connection remains open or until the client re-authenticates. The server can grant privileges to the client based on its identity.
- #39 Rfc 1777This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. Specifications for two underlying services are defined here, though others are also possible. Transmission Control Protocol (TCP) The LDAPMessage PDUs are mapped directly onto the TCP bytestream. Server implementations running over the TCP should provide a protocol listener on port 389. Connection Oriented Transport Service (COTS) The connection is established. No special use of T-Connect is made. Each LDAPMessage PDU is mapped directly onto T-Data.
- #40 References – LDAP Directories Explained. – LDAP Operations – starting page 85 “This slide give more detail about LDAP Authentication Operations”There are two LDAP authentication operations, bind and unbind, and one control operation, abandon.The bind operation is how a client authenticates itself to the directory. It does so by providing a distinguished name and a set of credentials. The server checks whether the credentials are correct for the given DN and, if they are, notes that the client is authenticated as long as the connection remains open or until the client re-authenticates. The server can grant privileges to the client based on its identity.There are several different types of bind methods. In a simplebind, the client presents a DN and a password in cleartext to the LDAP server. The server verifies that the password matches the password value stored in the userpassword attribute of the entry and, if so, returns a success code to the client.The simple bind does send the password over the network to the server in the clear. However, you can protect against eavesdroppers intercepting passwords by encrypting the connections using secure sockets layer (SSL) or TLS, which are discussed in the next section. In the future, LDAPv3 will include a digest-based authentication method that does not require that a cleartext password be sent to the server.LDAPv3 also includes a new type of bind operation, the SASL bind. SASL is an extensible, protocol-independent framework for performing authentication and negotiation of security parameters. With SASL, the client specifies the type of authentication protocol it wants to use. If the server supports the authentication protocol, the client and server perform the agreed-upon authentication protocol.For example, the client could specify that it wants to authenticate using the Kerberos protocol . If the server knows how to speak the Kerberos protocol, it indicates this to the client that sends a service ticket for the LDAP service. The server verifies the service ticket and returns a mutual authentication token to the client. Whenever the Kerberos authentication completes, the SASL bind is complete and the server returns a success code to the client. SASL can also support multistep authentication protocols such as S/KEY.Incorporation of SASL into LDAPv3 means that new authentication methods, such as smart cards or biometric authentication, can be easily implemented for LDAP without requiring a revision of the protocol.The second authentication operation is the unbind operation. The unbind operation has no parameters. When a client issues an unbind operation, the server discards any authentication information it has associated with the client's connection, terminates any outstanding LDAP operations, and disconnects from the client, thus closing the TCP connection.The abandon operation has a single parameter: the message ID of the LDAP operation to abandon. The client issues an abandon operation when it is no longer interested in obtaining the results of a previously initiated operation. Upon receiving an abandon request, the server terminates processing of the operation that corresponds to the message ID. The abandon request, typically used by GUI clients, is sent when the user cancels a long-running search request.
- #41 References – LDAP Directory Explained – Search, starting on page 73When an LDAP client asks a directory server for information, it does so by passing a relatively simple set of search criteria that tells the server a number of things:• What part of the directory tree will be searched.• What qualities must returned entries contain or not contain.• What information from matching entries should be returned.- baseObject: An LDAPDN that is the base object entry relative to which the search is to be performed.- scope: An indicator of the scope of the search to be performed. The semantics of the possible values of this field are identical to the semantics of the scope field in the X.511 Search Operation.- derefAliases: An indicator as to how alias objects (as defined inX.501) are to be handled in searching. - sizelimit: A sizelimit that restricts the maximum number of entries to be returned as a result of the search. A value of 0 in this field indicates that no client-requested sizelimit restrictions are in effect for the search. Servers may enforce a maximum number of entries to return.- timelimit: A timelimit that restricts the maximum time (in seconds) allowed for a search. A value of 0 in this field indicates that no client-requested timelimit restrictions are in effect for the search.- typesOnly: An indicator as to whether search results will contain both attribute types and values, or just attribute types. Setting this field to TRUE causes only attribute types (no values) to be returned. Setting this field to FALSE causes both attribute types and values to be returned.- filter: A filter that defines the conditions that must be fulfilled in order for the search to match a given entry.- attributes: A list of the attributes to be returned from each entry which matches the search filter. There are two special values which may be used: an empty list with no attributes, and the attribute description string \"*\". Both of these signify that all user attributes are to be returned. (The \"*\" allows the client to request all user attributes in addition to specific operational attributes).
- #42 References – LDAP System Administration – Chapter 4 – Building a company white pages, starting on page 70Parameters of the Add Request are:- entry: the Distinguished Name of the entry to be added. Note that the server will not dereference any aliases in locating the entry to be added.- attributes: the list of attributes that make up the content of the entry being added. Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply the createTimestamp or creatorsName attributes, since these will be generated automatically by the server.Parameters of the Modify Request are:- object: The object to be modified. The value of this field contains the DN of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified.- modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively:add: add values listed to the given attribute, creating the attribute if necessary;delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion;replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist.Delete Request - The Delete Operation allows a client to request the removal of an entry from the directory.The Delete Request consists of the Distinguished Name of the entry to be deleted. Note that the server will not dereference aliases while resolving the name of the target entry to be removed, and that only leaf entries (those with no subordinate entries) can be deleted with this operation. The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response. *** THE ENTRY BEING DELETED CANNOT BE A CONTAINER WITH CHILD ENTRIES **Modify DN Operation - Parameters of the Modify DN Request are:- entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries.- newrdn: the RDN that will form the leftmost component of the new name of the entry.- deleteoldrdn: a boolean parameter that controls whether the old RDN attribute values are to be retained as attributes of the entry, or deleted from the entry.- newSuperior: if present, this is the Distinguished Name of the entry which becomes the immediate superior of the existing entry.
- #44 Reference – 1) Thesis “Directory Services for Linux” – Chapter 4 “Access Control and Security Layers”2) LDAP Programming with Java – Chapter 7 “Securing the Data” 3) LDAP Directories Explained - Chapter 5 – Directory Management, section “Directory Security”, beginning page 179 4) Manning eBook – Chapter 13 “Application Security and Directory Services”“Now we will talk about LDAP’s Security Model” …. There are several “issues” involved in Security Authentication is the process of verifying that a peer entity in a connection is genuine. For use in computer systems the identity of a peer entity is generally represented by an alphanumeric string of some form, for example, DNs, fully qualified domain names,user ids or social security numbers. To assert the claimed identity, credentials are passed between the communication parties.Several Authentication MechanismsBind with passwordSASL..the simple authentication and security layer, was developed by John Myers of Netscape. SASL (pronounced \"sazzle\") is a generic framework for negotiating authentication and security layer semantics in application-layer protocols. SASL enables support for authentication, encryption, and signing services. Although it provides no security itself, SASL allows application protocols such as LDAP to negotiate security parameters. LDAP version 3 includes native support for SASL. At the time of this writing, SASL is a Proposed Internet Standard, documented in RFC 2222.Session EncryptionSecurity layers protect data on its way between the communication peers from1. being altered in transit. This is known as integrity protection.2. being overheard by an unauthorized person. This in known as privacy protection (confidentialty)Security layers are commonly provided at the transport layer. The relevant standards in this field are the Secure Socket Layer (SSL) [13] and its successor, Transport Layer Security (TLS) [8]. But also Kerberos and SASL include the ability to establish asecurity layer. With IPsec a standard has emerged, which offers support for a security layer at the network layer of the Internet Protocol. LDAP over SSL (LDAPS5) is available in most mainstream products. Support forTLS via the StartTLS extended request [21] is so far only available in OpenLDAP andMessagingDirect products.Authorization is the process of determining, whether the requested access to a resource may be granted. The rules—often called Access Control Lists (ACL)—that govern this process are expressed in terms of Access Control Factors (ACF). Common ACFs in the LDAP context are [93]:• The authentication method.• The authorization identity.• The kind of requested operation (e.g. search or modify).• The entries and attributes affected by the operation.
- #45 Security ModelThe bind operation allows an LDAP client to authenticate. This in turn allows the LDAP server to authorize access to a set of entries and attributes based on any access control lists it may be using. Figure 13.3 shows this process.LDAP has long supported anonymous and simple authentication. Anonymous means exactly what it sounds like, and simple authentication means that passwords are transmitted in the clear over the network.Earlier LDAP vendors added a level of security in the form of SSL encryption, which allows passwords to be encrypted by the virtue of having encryption for the entire session.SSL also adds the ability to authenticate the server using certificates. More recent standards have required support for the SASL, which allows client and server to negotiate and use different mechanisms to authenticate each other.In LDAPv2, LDAP clients provide a DN and a clear-text password to the server. The password is the authentication credential and the DN defines the scope of authentication. However, this method is susceptible to a malicious user who steals passwords by eavesdropping on the network. This has been prevented lately by using the Kerberos authentication protocol. Since LDAPv3, SASL handles authentication and security. SASL is merely a standard way for plugging in different authentication protocols that do the actual work of authentication and enforcement of security. As we have seen, SSL is one such protocol that plugs into the SASL model and is almost the de facto standard for secure communications over TCP/IP networks. The successor to SSL is TLS (Transport Layer Security), which is also a pluggable authentication scheme that is supported by several LDAP vendors. In future, LDAP implementations are expected to use the startTLS mechanism to encrypt a communication channel and TLS for the clients to authenticate themselves and to verify identity of servers. Please see RFC 2487 for more information on startTLS. Currently LDAP does not have an inherent standard means to enforce access control. However, most LDAP vendors have some access control model built into their implementations. Access control is of significance because it allows the owners of information to modify it. For example, the access control policy of a directory can be set up such that a user can change his telephone number and address but cannot modify any other entries, a manager can modify his entry and all the entries belonging to his subordinates, or a facilities administrator can modify the room number and telephone number of all employees and nothing else.
- #46 Reference – LDAP Directories Explaining – Chapter 5 – Directory Management, section “Directory Security”, beginning page 179There are Different Types of AuthenicationNo AuthenticationIn many applications, it is not necessary—and sometimes not desirable—that clients authenticate themselves to the server. This is usually true for read access to public data. Since the data is public, there is no need to restrict access to specific users. It should be in the service provider’s interest to fashion the access for customers as easy as possible. Any uncalled for efforts might drive the customer elsewhere. From the client’s perspective, not giving away too much information about the user helps in upholding privacy. This prevents the server’s operator from building detailed customerprofiles. If no authentication is performed, the client is said to be “anonymous”. This is also theinitial state for the client, after a connection has been opened to the server.Basic AuthenticationThe authentication protocol with plain text passwords works as follows:1. The server asks the client for username and password.2. The client responds with username and password.3. The host compares the password with the value on record for the specified username.The major disadvantage of plain text passwords is that they are easily to compromise. Anyone who can physically eavesdrop on the communication between client and server will learn the password (and the authentication identifier). Once obtained, the credentials can be reused until the password is changed. The attacker might even change the password himself and thus lockout its original holder. The Simple Authentication and Security Layer (SASL) provides “a method for adding authentication support to connection-based protocols” [71]. SASL allows application layer protocols to make use of different authentication mechanisms. To implement SASL, a protocol needs to define an operation by which a user can authenticate himself to a server. This operation must include the name of the authentication mechanism to use and may include an authorization identifier if it is different from the authenticationidentifier.Often some way is provided, by which a client can determine which mechanisms the server supports. In LDAP, these can be requested by retrieving the “supported- SaslMechanisms” attribute from the server’s rootDSE.SASL mechanisms that have been defined include:• ANONYMOUS (defined in [76], see also 4.1.2.1)• PLAIN (defined in [77], see also 4.1.2.2)• DIGEST-MD5 (defined in [56], see also 4.1.2.3)• GSSAPI (defined in [71], see also 4.1.2.4)• EXTERNAL (defined in [71]). By using the EXTERNAL mechanism, the authenticationidentity is determined form an external source, e.g. from certificates thathave been exchanged during the negotiation of a security layer with SSL or TLS.
- #47 Reference –1) LDAP Programming with Java, Chap. 7 “Securing the Data 2) LDAP Directories Explained – Chapter 5 – Directory Management, section “Directory Security”, beginning page 179 “This slide shows the CONTEXT of the Security Layer in LDAP”Security layers protect data on its way between the communication peers from1. being altered in transit. This is known as integrity protection.2. being overheard by an unauthorized person. This in known as privacy protection.Security layers are commonly provided at the transport layer. The relevant standards in this field are the Secure Socket Layer (SSL) [13] and its successor, Transport Layer Security (TLS) [8]. But also Kerberos and SASL include the ability to establish a security layer. With IPsec a standard has emerged, which offers support for a security layer at the network layer of the Internet Protocol.LDAP over SSL (LDAPS5) is available in most mainstream products. Support forTLS via the StartTLS extended request [21] is so far only available in OpenLDAP and MessagingDirect products.The Secure Socket Layer (SSL) protocol was devised to provide both authentication and data security. It encapsulates the TCP/IP socket so that basically every TCP/IP application can use it to secure its communication.SSL was developed by Netscape and the current version is 3.0. Transport Layer Security (TLS) is an evolving open standard, currently in the state of an Internet Draft, being worked on at the IETF. It is based on SSL 3.0 with only a few minor differences, and it provides backwards compatibility with SSL 3.0. It is assumed that TLS will replace SSL. The following discussion is equally valid for both SSL and TLS. SSL/TLS supports server authentication (client authenticates server), client authentication (server authenticates client), or mutual authentication. In addition, it provides for privacy by encrypting data sent over the network. SSL/TLS uses a public key method to secure the communication and to authenticate the counterparts of the session. This is achieved with a public/private key pair. They operate as reverse functions to each other, which means data encrypted with the private key can be decrypted with the public key and vice versa. The assumption for the following considerations is that the server has its key pair already generated. This is usually done when setting up the LDAP server.
- #48 “This slide shows the client server interactions during an SSL session”1. As a first step, the client asks the server for an SSL/TLS session. The client also includes the SSL/TLS options it supports in the request.2. The server sends back its SSL/TLS options and a certificate which includes, among other things, the server’s public key, the identity for whomthe certificate was issued (as a distinguished name), the certifier’s name and the validity time. A certificate can be thought of the electronicequivalent of a passport. It has to be issued by a general, trusted Certificate Authority (CA) which vouches that the public key really belongsto the entity mentioned in the certificate. The certificate is signed by the certifier which can be verified with the certifier’s freely available public key3. The client then requests the server to prove its identity. This is to make sure that the certificate was not sent by someone else who intercepted it on a former occasion.4. The server sends back a message including a message digest (similar to a check sum) which is encrypted with its private key. A message digest that is computed from the message content using a hash function has two features. It is extremely difficult to reverse, and it is nearly impossible to find a message that would produce the same digest. The client can decrypt the digest with the server’s public key and then compare it with the digest it computes from the message. If both are equal, the server’s identity is proved, and the authentication process is finished.5. Next, server and client have to agree upon a secret (symmetric) key used for data encryption. Data encryption is done with a symmetric keyalgorithm because it is more efficient than the computing-intensive public key method. The client therefore generates a symmetric key, encrypts itwith the server’s public key, and sends it to the server. Only the server with its private key can decrypt the secret key.6. The server decrypts the secret key and sends back a test message encrypted with the secret key to prove that the key has safely arrived.They can now start communicating using the symmetric key to encrypt the data.
- #50 References – Safari book – Understanding and Deploying LDAP Directory Services, Chapter 9 – Topology Design ; Background reading for this slide should include ALL of Chapter 9 section “Gluing the Directory Together: Knowledge References ( assumes knowledge of “directory partitions”, covered in prior sections of chapter 9.When a client sends a request to an LDAP server, the response to the client may be a referral. The client can then choose to follow the referral by querying the other LDAP server contained in the referral returned by the first LDAP server. Referrals are not followed (resolved) by servers. This can improve server performance by off-loading the work of contacting other servers to the client.This figure illustrates a client following a referral. An LDAP client requests information from LDAP Server 1 (1). This request is answered with a referralto LDAP Server 2 (2). The LDAP client then contacts LDAP Server 2 (3). LDAP Server 2 provides the requested data to the client (4).
- #51 Gluing the Directory Together: Directory Partions and Knowledge References So far, we've described the directory partition in terms of the entries it contains. However, we still need some way to describe the relationships between directory partitions. The LDAP and X.500 standards define these relationships in terms of knowledge references—pointers to directory information held in another partition. There are two types of knowledge references:Immediate superior knowledge references. This type of knowledge reference points upward in the DIT toward the root and ties the naming context to its ancestor. In effect, it provides the \"hook\" at the top of the directory partition that you use to hang a partition from its ancestor. Subordinate references. These knowledge references point downward in the DIT to other partitions. They are the hooks onto which you hang other naming contexts. Figure 9.6 illustrates how directory partitions fit together into a larger DIT. In this example, the partition root ou=London, dc=airius, dc=com denotes the top of the partition. The partition contains the partition root and all the entries underneath it, except for those entries held in partitions pointed to by the two subordinate references, ou=Accounting, ou=London, dc=airius, dc=com and ou=Engineering, ou=London, dc=airius, dc=com. An immediate superior knowledge reference also points upward in the DIT, connecting this partition to its parent partition. Knowledge references always come in pairs; although not shown, the parent partition would thus have a subordinate reference pointing to the partition in the figure.Safari book, “Understanding and Deploying LDAP Directory Services”, Chapter 9, Topology Design, section “Gluing the Directory Together”, **** OPENING TEXT IN THAT SECTION ACCOMPANIES THIS FIGURE ****
- #52 Resources – RFC2255An LDAP URL, defined by RFC 2255, is represented by the LDAPUrl class and composed of the following:\"ldap://\" [ hostName [\":\" portNumber] ] \"/\" baseDN [\"?\" attributeList [\"?\" scope \"?\" filterString [\"?\" extensions ] ] ] whereAll text enclosed by quotation marks is literal.hostName and portNumber identify the location of the LDAP server.baseDN specifies the name of an entry within the given directory (the entry represents the starting point of the search).attributeList contains a comma-delimited list of attributes to retrieve (if not specified, fetch all attributes).scope is one of the following:\"base\" indicates that this is a search only for the specified entry.\"one\" indicates that this is a search for matching entries one level under the specified entry (and not including the entry itself).\"sub\" indicates that this is a search for matching entries at all levels under the specified entry (including the entry itself).If not specified, the scope is base by default.filterString is a human-readable representation of the search filter, of the same type as is used as the search filter parameter in the LDAPConnection.search methods. This value is used only for one-level or subtree searches.extensions is an optional list of comma-separated extensions to the information provided by the other components. RFC 2255 defines one such extension, bindname, for specifying a DN to authenticate as. This extension is not widely used, because a corresponding password cannot be provided with the URL (the RFC advises against passing a reusable password for URL processing, for security reasons). Any other extensions must be prefixed with \"X-\" or \"x-\". An extension may have a value: for example, bindname=uid=paul%2cou=people%2co=acme.com. Note that commas must be URL-encoded in an extension value because they separate extensions. Each extension may be prefixed with an exclamation point, in which case the client (the SDK or the application) should consider the extension mandatory and not execute the search if it cannot process the extension. For example, ldap:///ou=people,o=acme.com??sub?(sn=jensen)?!X-QUICKSEARCH.
- #53 References – manning LDAP eBook – Chapter 5 “Exchanging directory information”LDAP Data Interchange Format (LDIF)LDIF can be a simple way of representing directory information as text. Nearly all directory servers support it for import and export, and most LDAP APIs will read or write it as necessary. After several years as a de facto standard, LDIF is now properly documented as RFC 2849 from the IETF.In addition to representing full entries, LDIF can also be used to exchange entrychanges and even schemas, when combined with the textual representation of schemasthat we discussed in chapter 2.LDIF is restricted to printable text. This means binary values must be encodedusing the Base64 standard. (Base64 is a standard that is commonly used in a wide variety of situations and is not specific to directory services.)
- #54 Several of the “Patterns for eBusiness” depend on the services provided by DirectoriesWe will now show how “Directory Services” fit into several of these eBusiness Patterns.What the Patterns consist ofWhich Patterns Rely on Directory ServicesHow several of these patterns incorporate Directory services into their architecturePatterns for e-business are a group of reusable assets that can help speed the process of developing Web-based applications. This site breaks down these reusable assets into the following elements: Business patterns identify the interaction between users, businesses, and data. Business patterns are used to create simple, end-to-end e-business applications. Integration patterns connect other Business patterns together to create applications with advanced functionality. Integration patterns are used to combine Business patterns in advanced e-business applications. Composite patterns are combinations of Business patterns and Integration patterns that have themselves become commonly used types of e-business applications. Composite patterns are advanced e-business applications. Custom designs are similar to Composite patterns, as they combine Business patterns and Integration patterns to form an advanced, end-to-end solution. These solutions, however, have not been implemented to the extent of Composite patterns, but are instead developed to solve the e-business problems of one specific company, or perhaps several enterprises with similar problems. Application and Runtime patterns are driven by the customer's requirements and describe the shape of applications and the supporting runtime needed to build the e-business application. Product mappings to populate the solution. The product mappings are based on proven implementations. Guidelines for the design, development, deployment, and management of e-business applications. The Patterns leverage the experience of IBM architects to create solutions quickly, whether for a small local business or a large multinational enterprise. As shown in the following figure, customer requirements are quickly translated through the different levels of Patterns assets to identify a final solution design and product mapping appropriate for the application being developed.
- #55 There are four primary Business patterns:Self-Service pattern, formerly known as the User-to-Business pattern, whichdescribes situations where users are interacting with a business application toview or update data.Collaboration pattern, formerly known as the User-to-User pattern, whichdescribes the interaction between users. This would included e-mail andworkflow processes.Information Aggregation pattern, formerly known as the User-to-Data pattern,which describes situations where users access and manipulate largeamounts of data collected from multiple sources.Extended Enterprise pattern, formerly known as the Business-to-Businesspattern, which describes the programmatic interaction between two distinctbusinesses.Integration patterns allow us to tie together multiple Business patterns to solve aproblem. The Integration patterns include:Access Integration pattern, which provides the front-end integration ofmultiple services and information through a common portal. It is responsiblefor handling multiple client device types, single sign-on and personalization,and for providing a common look and feel to the application interfaces.Application Integration pattern, which provides for the seamless back-endintegration of multiple applications and data without direct access by the user.
- #56 Collaboration - Sometimes called User-to-User, the Collaboration business pattern addresses the interactions and collaborations between users. This pattern can be observed in solutions that support small or extended teams who need to work together in order to achieve a joint goal. Solution requires a set of collaboration services, which can include support for: A directory that allows users to locate others on the network. This directory can also store security and access privileges associated with each user. Different types of data, from simple text to sophisticated and complex large data elements such as streaming audio and video. Transient and persistent data sources that facilitate the collaboration. Integration Patterns – The natural consequence of the \"integration points\" that enable interaction between the four Business patterns above is that today's more complex solutions can be built by combining these Business patterns. This is done by using one or more Integration patterns, which integrate multiple applications, multiple modes of access, and multiple sources of information to build one seamless application. Integration patterns are differentiated from Business patterns in that they do not themselves automate specific business problems. Rather, they are used within Business patterns to support more advanced functions, or to make Composite patterns feasible by allowing the integration of two or more Business patterns.Inspecting a number of complex e-business systems, across many industries, two distinct sets of designs can be observed. Each of these design sets forms the basis for an Integration pattern:The Access Integration pattern The Access Integration pattern gives users a single, consistent, and seamless access mechanism to various applications that would otherwise require the use of several different access mechanisms. This Integration pattern is useful when: Users need access to multiple applications and information sources without every application requiring its own sign-on to establish a separate security context.
- #58 As shown in the figure above, the main participants in this Application pattern include: A client that is a peer to other clients with which it collaborates Each client will have a local address book where users can set up the users that they communicate with on a regular basis. The users can also set up groups of users and collaborate with them collectively. The local address book will also store the address of the server to which it needs to connect in order to initiate collaboration functions. The clients could optionally contain software programs (such as word processors, spread sheet programs, and so on) that can be shared across the network This Application pattern requires that each client register with the server. Once a client has registered with a server, the user’s data and profile is stored in a directory on the server. The client will connect to the server. This server will authenticate the user by validating their access privileges against the Directory. The server will notify them of other users who are online at that point in time and return the addresses of these clients on the network. The client can then use this information to initiate direct collaboration with other clients that are online at that time. In other words, the client uses the server for authorization, authentication, and directory lookup.
- #59 This pattern can be observed in Solutions such as: Customer-facing solutions such as online stores that provide a personalized user interface that can be customized by users to suit their individual requirements and preferences. Examples include Online Portals that allow users to customize their interactions with the portal and specify their preferences for multiple access devices such as a browser, a custom client, Personal Digital Assistants, Web-enabled phones, and interactive set-top boxes. OverviewThe Access Integration pattern gives users a single, consistent, and seamless access mechanism to various applications that would otherwise require the use of several different access mechanisms.Users need access to multiple applications and information sources without every application requiring its own sign-on to establish a separate security context. The Access Integration pattern, however, can be used to enable more complex e-business solutions composed of multiple Business patterns. For example, a browser-based, personalized portal can be developed by combining applications that automate the Self-Service business pattern and the Collaboration business pattern. Additionally, this personalized portal might add accessibility to mobile devices.A study of several e-business solutions that have successfully met these challenging requirements reveals the use of four recurring, common services, including: 1. Device Support service 2. Presentation service 3. Personalization service 4. Security and Administration service The objective of the Access Integration pattern is to externalize these services and make them selectable by developers of integrated solutions.
- #60 Application patterns for Access Integration are composed of the services mentioned in the previous slide (Device support, Presentation, Personalization, Security and Administration). Based on the specific installation needs of the application being built, developers can mix and match these services to facilitate consistent and seamless access to multiple applications. One commonly observed Application pattern for Access Integration that shows the role of Directory Services is presented in the slide that follows.
- #61 The Single Sign-On application patterns provide a framework for seamless application access through unified authentication services. One application pattern for Single Sign-On is shown here: It is a basic pattern where the single-sign on functions are performed in the Web tier.Business and IT DriversProvide single sign on across multiple applications Reduce Total Cost of Ownership (TCO) Reduce user administration cost The primary business driver for choosing this Application pattern is to provide seamless access to multiple applications with a single sign-on while continuing to protect the security of enterprise information and applications. Simplification and increased efficiency of user profile management is the main IT driver for Single Sign-On.SolutionThe Single Sign-On application pattern uses the Security and Administration service discussed above.This Application pattern is built using three logical tiers: Client, Single Sign-On, and Application. The Client tier represents the user interface client such as a browser, mobile phone, or PDA. The Single Sign-On tier implements the Security and Administration service, which provides a seamless sign-on capability across multiple applications. This tier uses a user profile data store, which is primarily read-only. However, this data store can also be used in a read/write manner to keep track of the last sign-on, the number of invalid sign-on attempts, and so on. The SSO tier intercepts all sign-on requests, authenticates the user, and establishes a user credential upon successful authentication. Subsequently, if the user tries to access another application that also requires a sign-on, this service automatically passes the user credential on to that application. The target application recognizes the user credential established by the security service and uses it for authorization locally. As a result, users can sign on once to access all the applications integrated using this Application pattern. The Application tier may represent a new application, a modified existing application, or an unmodified existing application.
- #62 Single Sign-on can be implemented by securing access through the Web tier. Web Single Sign-On runtime patternsSingle Sign-On (SSO) performed in the Web tier is appropriate for environments with no back-end systems or where access to back-end systems does not need to be executed under the Web user’s identity. Examples include e-commerce sites and customer portals.The key consideration in establishing a Web Single Sign-On solution is the diversity of the e-business environment. There are two key types of environments to consider: a homogeneous application server environment or a heterogeneous environment (multiple vendors/versions of application servers). One runtime pattern I shown here is called homogenous application server.The homogenous application server design shown here illustrates how a Web tier environment where all applications are implemented on the same application server can exploit that application server's security server for single sign-on functionality.The benefits of this design are that it enables a simple, effective security model for applications built within the same application server environment. The disadvantage is that it does not support applications outside the application server domain.
- #63 Combination Runtime pattern variation 1 It is possible to customize an Access Integration solution to take advantage of two Application patterns: Single Sign-On and Personalized Delivery. The two Runtime patterns for this design combine the nodes required to fulfill both functions. This combined Runtime pattern shown here is used when the situation calls for Web Single Sign-On and rules-based personalization. Both Application patterns are shown as overlays here to illustrate the location of the Application pattern tiers in the Runtime pattern. In addition, the Web server function was separated from the primary presentation and application server functions for added security.The Web server redirector node allows the business logic to be located in the internal network, giving it the protection of both firewalls. The Web server redirector performs limited functions. It serves static HTML pages, forwarding the rest of the requests to the Web presentation server. There is limited security at this node. Webseal could be used to enhance this.The Web presentation server, together with the Directory server, provides Single Sign-On capability, allowing users to sign on one time in order to access multiple applications. It runs the servlets and JSPs necessary for presenting the data to the user. It interacts with the personalization server to build customized output for users based on identity or role.The personalization server classifies the users and determines specific content suitable for presentation to the user.Each node in the internal network uses the directory and security services node as a central location for security information, making the single sign-on possible.
- #64 The implementation of this runtime using the IBM WebSphere product family uses IBM WebSphere Portal Server to provide the Web presentation server functions. IBM WebSphere Personalization can be installed separately, or as a part of the IBM WebSphere Portal Server, to provide the personalization functions. These products both run on top of IBM WebSphere Application Server Advanced Edition.The product mapping for the Directory and Security Services uses IBM’s implementation of an LDAP server, currently called “IBM Directory Server 5.1”.<number>
- #65 The links mentioned above are a good starting point for LDAP information. Information on the work of the IETF standards bodies (including the LDAP working groups) can be found at http://www.ietf.org/.