DEV-4: OpenEdge in an LDAP World

1. DEV-4: OpenEdge� in an LDAP World This is Exchange 2007 session �DEV-4: OpenEdge in an LDAP World�. My name is Michael Jacobs, and I�m a Development Architect in the Progress OpenEdge group. This is 60 minute intermediate session that is targeted for OpenEdge application architects and developers. In it I make the assumption that you have had some experience in working with native OS shared-libraries. If, not you can still benefit from this session. I occasionally get questions about OpenEdge authenticating a LDAP user. I�ve worked with LDAP and user authentication on and off for over 10 years, and I was curious to see if it would be accessible directly from the ABL. The answer was yes, and I thought it simple enough to be an interesting topic. So my goal for this session is to introduce you to the world of developing LDAP client applications and show you how LDAP user authentication can be performed from your OpenEdge application. This session will not enable you to design and implement an LDAP directory, I�d need more time for that. What the session will do is give you, as an application developer, the foundational information necessary to understand the LDAP environment and begin adding LDAP client functionality to your OpenEdge application. The information in these slides builds over time, so for that reason I ask that you hold your questions until the end to ensure that I do not already have the question answered later in the session. This is Exchange 2007 session �DEV-4: OpenEdge in an LDAP World�. My name is Michael Jacobs, and I�m a Development Architect in the Progress OpenEdge group. This is 60 minute intermediate session that is targeted for OpenEdge application architects and developers. In it I make the assumption that you have had some experience in working with native OS shared-libraries. If, not you can still benefit from this session. I occasionally get questions about OpenEdge authenticating a LDAP user. I�ve worked with LDAP and user authentication on and off for over 10 years, and I was curious to see if it would be accessible directly from the ABL. The answer was yes, and I thought it simple enough to be an interesting topic. So my goal for this session is to introduce you to the world of developing LDAP client applications and show you how LDAP user authentication can be performed from your OpenEdge application. This session will not enable you to design and implement an LDAP directory, I�d need more time for that. What the session will do is give you, as an application developer, the foundational information necessary to understand the LDAP environment and begin adding LDAP client functionality to your OpenEdge application. The information in these slides builds over time, so for that reason I ask that you hold your questions until the end to ensure that I do not already have the question answered later in the session.

2. DEV-4: OpenEdge in an LDAP World Agenda Introduction to LDAP Directory Service fundamentals Exploring the LDAP API LDAP Authentication Process Using LDAP from the ABL language This session will have to cover a brief introduction to LDAP so that everyone has some basic knowledge, Directory Service fundamentals to know understand the basic functionality, a look at the LDAP programming API, since most people will use LDAP for user authentication an LDAP authentication process, and finally some unique things about using native OS LDAP API libraries from the ABL.This session will have to cover a brief introduction to LDAP so that everyone has some basic knowledge, Directory Service fundamentals to know understand the basic functionality, a look at the LDAP programming API, since most people will use LDAP for user authentication an LDAP authentication process, and finally some unique things about using native OS LDAP API libraries from the ABL.

3. DEV-4: OpenEdge in an LDAP World LDAP v3 Client-server wire protocol for accessing and managing objects in a Directory Service Originated from the X standards as DAP (Directory Access Protocol) and X.500 Directory Open standard supported by many Programming languages: C, Perl, Java, � Software vendors Microsoft Active Directory Sun Novell OpenLDAP.org LDAP version 3 is a standards based API for a network wire protocol. It originated with the X standards and is used to interface you to an X.500 standard Directory Service. As an open standard, the LDAP API is available from multiple operating systems, programming languages, and from multiple software vendors. The are a number of LDAP directory service vendors, OpenLDAP, Sun, and Microsoft�s Active Directory are well known examples. One of the nice things is that you have a choice of open source LDAP tools available to you. LDAP version 3 is a standards based API for a network wire protocol. It originated with the X standards and is used to interface you to an X.500 standard Directory Service. As an open standard, the LDAP API is available from multiple operating systems, programming languages, and from multiple software vendors. The are a number of LDAP directory service vendors, OpenLDAP, Sun, and Microsoft�s Active Directory are well known examples. One of the nice things is that you have a choice of open source LDAP tools available to you.

4. DEV-4: OpenEdge in an LDAP World LDAP Directory Service Extensible, general purpose, object storage Used for storing frequently read, seldom written information Single unified view of distributed and replicate object storage across multiple servers Primary OpenEdge application uses Single point of user authentication Access user account information and role membership Synchronize user-accounts from LDAP A Directory Service is just general purpose information storage that is distributed across an organization�s intranet. It�s primary purpose is to gives distributed applications a single source of information storage and administrators open access from multiple operating systems and utilities. It is optimized for read-often, write-seldom. It is not a database, if you think you can keep frequently changed context information there, you may have performance issues. It is not a database, even though it does support transactions. It does support replication and the ability to segment the information storage space across the organization�s servers and networks. A Directory Service is just general purpose information storage that is distributed across an organization�s intranet. It�s primary purpose is to gives distributed applications a single source of information storage and administrators open access from multiple operating systems and utilities. It is optimized for read-often, write-seldom. It is not a database, if you think you can keep frequently changed context information there, you may have performance issues. It is not a database, even though it does support transactions. It does support replication and the ability to segment the information storage space across the organization�s servers and networks.

5. DEV-4: OpenEdge in an LDAP World Agenda Introduction to LDAP Directory Service fundamentals Exploring the LDAP API LDAP Authentication Process Using LDAP from the ABL language

6. DEV-4: OpenEdge in an LDAP World Mastering Directory Services LDAP object storage model LDAP object name-space model Connect and search for data objects Extracting data object�s information For you to effectively use LDAP, you need 4 skills: Understand the object storage model, as each site can be different Understand the object name-space model so that you can find information How to connect and search for information, because each LDAP installation may not put the same type of information in the same place And obviously how to extract the information you need once you find it. For you to effectively use LDAP, you need 4 skills: Understand the object storage model, as each site can be different Understand the object name-space model so that you can find information How to connect and search for information, because each LDAP installation may not put the same type of information in the same place And obviously how to extract the information you need once you find it.

7. DEV-4: OpenEdge in an LDAP World Directory Service Storage Model LDAP central concept is the object Objects represent real-world concepts People Organizations Objects, etc.. Objects are defined in extensible schema files, and as objects one object can extend another and therefore inherit its information fields For instance, your product can define its own objects or add your application data to existing objects. A common issue is user-accounts. Your application has user-account information specific to your application. You have three options: Create your own user-objects, something you probably want to avoid Create a new user-object that extends a user object that are already defined in the LDAP directory schema (makes it hard to use these attributes in other applications) Add your application attributes to the user object currently used by the company (best option) This is not a massive task, but some companies will not allow you to extend their directory objects.LDAP central concept is the object Objects represent real-world concepts People Organizations Objects, etc.. Objects are defined in extensible schema files, and as objects one object can extend another and therefore inherit its information fields For instance, your product can define its own objects or add your application data to existing objects. A common issue is user-accounts. Your application has user-account information specific to your application. You have three options: Create your own user-objects, something you probably want to avoid Create a new user-object that extends a user object that are already defined in the LDAP directory schema (makes it hard to use these attributes in other applications) Add your application attributes to the user object currently used by the company (best option) This is not a massive task, but some companies will not allow you to extend their directory objects.

8. DEV-4: OpenEdge in an LDAP World Directory Service Storage Model User accounts person, inetOrgPerson, user DNS domain server domainComponent (dc) A company & its organizational hierarchy organization (o) & organizationalUnit (ou) <private object definition> An example of common Directory Service objects you will encounter is: A hierarchy of user account objects A DNS domain component servers. Object that allow representation of a company�s organizational structure If none of the predefined LDAP objects meet your needs, you can always define your own object and register its OID so that other applications can use it. An example of common Directory Service objects you will encounter is: A hierarchy of user account objects A DNS domain component servers. Object that allow representation of a company�s organizational structure If none of the predefined LDAP objects meet your needs, you can always define your own object and register its OID so that other applications can use it.

9. DEV-4: OpenEdge in an LDAP World Directory Service Storage Model Objects store data as Attributes that have a set of characteristics: A data type that is either binary or text A full attribute name A value An optional alias name as a shortcut for longer descriptive full names Each attribute can be set as required or optional in the schema, which gives UIs the ability to discover what is required before creating new entries. Like all good storage, an attribute will support multiple values. Objects store data as Attributes that have a set of characteristics: A data type that is either binary or text A full attribute name A value An optional alias name as a shortcut for longer descriptive full names Each attribute can be set as required or optional in the schema, which gives UIs the ability to discover what is required before creating new entries. Like all good storage, an attribute will support multiple values.

10. DEV-4: OpenEdge in an LDAP World Common Attribute Data Types DirectoryString (UTF-8 character string) DistinguishedName Boolean Integer NumericString OID OctetString GeneralizedTime <private data-type> LDAP has a number of predefined (via OID) data types that you can work with. Here is a partial list that will probably cover most of your application needs. If your application needs something special, you can always define your own and register its OID so that other applications can know how to work with it and use it. LDAP has a number of predefined (via OID) data types that you can work with. Here is a partial list that will probably cover most of your application needs. If your application needs something special, you can always define your own and register its OID so that other applications can know how to work with it and use it.

11. DEV-4: OpenEdge in an LDAP World User Account Entry Attributes objectClass commonName (cn) telephoneNumber description locality (l) organization (o) userid (uid) mail country (c) <private attribute> sAMAccountName* userPrincipalName* mobile* lastLogon* displayName* userWorkstations* userSharedFolder* maxStorage* primaryGroupID* . . . There are many commonly defined attribute names. The list on the left shows common ones that appear in most Directory Service implementations, and the right shows items that are specific to Active Directory. In general, Active Directory supplies user account objects with many more user account controls. Note that if you authenticate directly to Active Directory from your ABL application, many of these attributes need to be checked lest you incur the wrath of the local Active Directory administrator. I�ve bolded the ones that you may make the most use of in authenticating LDAP user accounts. There are many commonly defined attribute names. The list on the left shows common ones that appear in most Directory Service implementations, and the right shows items that are specific to Active Directory. In general, Active Directory supplies user account objects with many more user account controls. Note that if you authenticate directly to Active Directory from your ABL application, many of these attributes need to be checked lest you incur the wrath of the local Active Directory administrator. I�ve bolded the ones that you may make the most use of in authenticating LDAP user accounts.

12. DEV-4: OpenEdge in an LDAP World Directory Service Name-space Model Instances of objects are stored as entries Entries are arranged in a hierarchical treelike structure Every entry is a node in the tree and may contain data Any entry may have 0 to n children of any object type Each entry has a unique distinguished name (DN) All entries are located and referenced via its DN All children of an entry must have a unique relative distinguished name (RDN), which is relevant to its parent�s DN Stored LDAP objects are referred to as Entries. Entries arranged in a hierarchical treelike structure that reflects political, geographic or organizational boundaries Position of entry in the hierarchy given by it's distinguished name (DN) Each component of a DN is called a relative distinguished name (RDN) The name-space is similar to a file system Names have comma separators Leaf nodes and non leaf nodes may have content All children of a parent entry must have different RDNs An RDN may be composed of one or more attribute/value pairs Alias entries are allowed, so the hierarchical structure can be circumvented Stored LDAP objects are referred to as Entries. Entries arranged in a hierarchical treelike structure that reflects political, geographic or organizational boundaries Position of entry in the hierarchy given by it's distinguished name (DN) Each component of a DN is called a relative distinguished name (RDN) The name-space is similar to a file system Names have comma separators Leaf nodes and non leaf nodes may have content All children of a parent entry must have different RDNs An RDN may be composed of one or more attribute/value pairs Alias entries are allowed, so the hierarchical structure can be circumvented

13. DEV-4: OpenEdge in an LDAP World Directory Service Name-space Model Here, I made up a sample name-space for the acme company that is based on DNS domain controller model. I�ll walk through the relating an entry instance to its full directory service identifying name. X.500 Directory Service names can be written both forward or backwards, the format I see most often is forwards. Forward names are right to left, with the leaf-node furthest left. Then each entry�s RDN extends its parent�s DN and is separated by a comma. Backwards names are right to left with the leaf-node last. Same comma separation, but in reverse order. Here, I made up a sample name-space for the acme company that is based on DNS domain controller model. I�ll walk through the relating an entry instance to its full directory service identifying name. X.500 Directory Service names can be written both forward or backwards, the format I see most often is forwards. Forward names are right to left, with the leaf-node furthest left. Then each entry�s RDN extends its parent�s DN and is separated by a comma. Backwards names are right to left with the leaf-node last. Same comma separation, but in reverse order.

14. DEV-4: OpenEdge in an LDAP World Directory Service Entry Example Here is a sample Directory Service entry: Note the full name of the entry instance, the object inheritance chain, common attributes such as the organization the user works for, and finally, two application specific items added just for your acme application. Notice that this entry is a user account for the Acme Corp. It has extended the standard inetOrgPerson object hierarchy and added two attributes for department name and employee-id. Here is a sample Directory Service entry: Note the full name of the entry instance, the object inheritance chain, common attributes such as the organization the user works for, and finally, two application specific items added just for your acme application. Notice that this entry is a user account for the Acme Corp. It has extended the standard inetOrgPerson object hierarchy and added two attributes for department name and employee-id.

15. DEV-4: OpenEdge in an LDAP World LDAP Connections Initialize an LDAP connection context �server[:port][ server[:port] �]� Set the connection context�s network options LDAP protocol version SSL on/off Timeouts � Connect and authenticate* (bind) to the directory as Anonymous LDAP user account DN & secret (password) Disconnect (�unbind�) when done with the service Managing connections to an LDAP service is a matter of four simple operations. You specify the primary server, and optionally any replica servers, to use. When you specify multiple servers, an LDAP client will search the primary and each replica until no servers remain in the list or it has successfully connected. Like any network component, you can set options to control the connection. Note: you must set the LDAP protocol version. For some reason they have left the default to version 2, and you really want to use version 3. You �bind� (i.e. authenticate) to the directory service, which sets your security access privilges. When you are all done, you �unbind� (i.e. disconnect) from the service. Managing connections to an LDAP service is a matter of four simple operations. You specify the primary server, and optionally any replica servers, to use. When you specify multiple servers, an LDAP client will search the primary and each replica until no servers remain in the list or it has successfully connected. Like any network component, you can set options to control the connection. Note: you must set the LDAP protocol version. For some reason they have left the default to version 2, and you really want to use version 3. You �bind� (i.e. authenticate) to the directory service, which sets your security access privilges. When you are all done, you �unbind� (i.e. disconnect) from the service.

16. DEV-4: OpenEdge in an LDAP World Searching a Directory Service LDAP searches require three components The entry�s DN of where to start the search [root] An attribute filter to determine which entries to find and return The scope of the search Search root entry Search root�s child entries Search root and its entire sub-tree LDAP searches return 0 � N entries Optionally returns each returned entry�s attributes LDAP searches are probably the most important and challenging operation you will run into, and one you have to master. You need three primary components: Where to start in the hierarchical name-space What set of entry attribute-value combinations to match, like a database where clause. And how much of the hierarchical name-space to search below the starting point. LDAP searches are the way you retrieve information from the Directory, just as a query returns information from a database. You can get zero or more entries from the search, and you have the option of having any accessible attributes returned for those entries. LDAP searches are probably the most important and challenging operation you will run into, and one you have to master. You need three primary components: Where to start in the hierarchical name-space What set of entry attribute-value combinations to match, like a database where clause. And how much of the hierarchical name-space to search below the starting point. LDAP searches are the way you retrieve information from the Directory, just as a query returns information from a database. You can get zero or more entries from the search, and you have the option of having any accessible attributes returned for those entries.

17. DEV-4: OpenEdge in an LDAP World Searching a Directory Service In this example I�ve used my name-space picture. In this case the search characteristics I need is the starting point fully qualified DN, the attribute-value pairs to match (cn=barb), and search the entire sub-tree below the starting point, but not including the starting point. The example shows finding the user account entry for the us employee that named �barb�. Because I want to localize the search as much as possible, I starting at the name �ou=us,0=acme corp�. Because that installation places no user-account child entries under the starting point entry, you will do an entire sub-tree search. Good policy is to always use configuration parameters for each of these search attributes. Then you can adapt to almost any company�s name-space design. In this example I�ve used my name-space picture. In this case the search characteristics I need is the starting point fully qualified DN, the attribute-value pairs to match (cn=barb), and search the entire sub-tree below the starting point, but not including the starting point. The example shows finding the user account entry for the us employee that named �barb�. Because I want to localize the search as much as possible, I starting at the name �ou=us,0=acme corp�. Because that installation places no user-account child entries under the starting point entry, you will do an entire sub-tree search. Good policy is to always use configuration parameters for each of these search attributes. Then you can adapt to almost any company�s name-space design.

18. DEV-4: OpenEdge in an LDAP World Directory Service Security Model Discretionary access controls applied at run-time Controls assigned to stored entries & their attributes Allowed LDAP users & groups Allowed user/group actions (read, write, search, � ) For example: Everyone can connect to LDAP without a user-id or password Certain accounts can search for entries Nobody can see a user-account entry�s password Only user & administrator changes password All LDAP directory vendors supply an security system to control user and administrator access. There are common characteristics to be aware of when using directories. Access controls are discretionary. They are applied according to the production site�s security policies. The access controls allow definitions for whom can do what for stored objects (i.e. entries) and their attributes An example might be that anyone can connect to the LDAP directory and search for user accounts. But when a user account is found, nobody can see the attribute�s value and only the user account owner and an administrator can change the password. All LDAP directory vendors supply an security system to control user and administrator access. There are common characteristics to be aware of when using directories. Access controls are discretionary. They are applied according to the production site�s security policies. The access controls allow definitions for whom can do what for stored objects (i.e. entries) and their attributes An example might be that anyone can connect to the LDAP directory and search for user accounts. But when a user account is found, nobody can see the attribute�s value and only the user account owner and an administrator can change the password.

19. DEV-4: OpenEdge in an LDAP World Retrieving LDAP Entries Complete the LDAP search Get the number of entries returned from the search Use first - next operations to access individual entries Get the entry�s DN for later use The LDAP API is pretty much like the ABL dynamic buffer & fields. The basic flow is: Get the number of attributes. A search can return a variable number deciding on which are present in the entry, and what the search asks for. Enumerate, using a first-next pattern, through the attribute list. For each attribute, get the entry�s DN for later use. The LDAP API is pretty much like the ABL dynamic buffer & fields. The basic flow is: Get the number of attributes. A search can return a variable number deciding on which are present in the entry, and what the search asks for. Enumerate, using a first-next pattern, through the attribute list. For each attribute, get the entry�s DN for later use.

20. DEV-4: OpenEdge in an LDAP World Retrieving LDAP Attribute Values Get the number of returned attributes  Use first - next functions to access individual attributesFor each attribute: Get the number of attribute values Get the array of attribute values Loop through the array of attribute values to retrieve individual values Release the memory allocated by the LDAP API library in step �b� The LDAP API is pretty much like the ABL dynamic buffer & fields. The basic flow is: Get the number of attributes. A search can return a variable number deciding on which are present in the entry, and what the search asks for. Enumerate, using a first-next pattern, through the attribute list. For each attribute, get the number of values and then get the memory address pointer to the attributes. You can then enumerate through the value pointers to the individual values. The LDAP API is pretty much like the ABL dynamic buffer & fields. The basic flow is: Get the number of attributes. A search can return a variable number deciding on which are present in the entry, and what the search asks for. Enumerate, using a first-next pattern, through the attribute list. For each attribute, get the number of values and then get the memory address pointer to the attributes. You can then enumerate through the value pointers to the individual values.

21. DEV-4: OpenEdge in an LDAP World Agenda Introduction to LDAP Directory Service fundamentals Exploring the LDAP API LDAP Authentication Process Using LDAP from the ABL language

22. DEV-4: OpenEdge in an LDAP World LDAP �C� Shared-library API Guidelines LDAP �C� functions all start with �ldap_� LDAP has synchronous & asynchronous API calls ldap_bind() (asynchronous) ldap_bind_s() (synchronous) Windows OS ANSI & WIDE (Unicode) function calls ldap_bind_sA (ANSI) ldap_bind_sW (WIDE) There are some common conventions for LDAP API functions, as well as some vendor specific ones. All LDAP API function calls start with �ldap_�. Some functions can work asynchronously, and when that is the case they append a �_s� suffix to the function name. The default being asynchronous. From the ABL, I recommend that you always do synchronous calls. On Windows, they also added the ability to use either ANSI or WIDE character strings. While I have been able to make the API work with WIDE characters from the ABL, I recommend that you use ANSI if at all possible. ANSI is also the Microsoft default when you use the common ldap_* function names (via C language macro definitions). As bonus slides, you will find ABL definitions for the most common ldap API functions. There are some common conventions for LDAP API functions, as well as some vendor specific ones. All LDAP API function calls start with �ldap_�. Some functions can work asynchronously, and when that is the case they append a �_s� suffix to the function name. The default being asynchronous. From the ABL, I recommend that you always do synchronous calls. On Windows, they also added the ability to use either ANSI or WIDE character strings. While I have been able to make the API work with WIDE characters from the ABL, I recommend that you use ANSI if at all possible. ANSI is also the Microsoft default when you use the common ldap_* function names (via C language macro definitions). As bonus slides, you will find ABL definitions for the most common ldap API functions.

23. DEV-4: OpenEdge in an LDAP World LDAP API Cheat-sheet In this and the next slide are quick-reference tables with the most common LDAP API functions, arranged by operation type. You will find that LDAP API functions are finely grained, and very abstract. All of these will be shown in a user authentication example later. At the end of the slide deck are bonus slides that detail the ABL function prototypes for these LDAP functions. In this and the next slide are quick-reference tables with the most common LDAP API functions, arranged by operation type. You will find that LDAP API functions are finely grained, and very abstract. All of these will be shown in a user authentication example later. At the end of the slide deck are bonus slides that detail the ABL function prototypes for these LDAP functions.

24. DEV-4: OpenEdge in an LDAP World LDAP API Cheat-sheet (cont)

25. DEV-4: OpenEdge in an LDAP World LDAP Search Filter Examples All entries: �(objectclass=*)� All entries with userid starting with �al� �(uid=al*)� Operators: = ~= <= >= & | ! Entry with object type �user� and user-id �alice� �( &(objectclass=person) (uid=alice) )� Entry with user-id �alice� and objectclass �user� or �inetOrgPerson� �( &(uid=alice) ( |(objectclass=person) (objectclass=inetOrgPerson) ) )� The LDAP search filters can be simple to very complex logical expressions. This is an area that you want to concentrate on as it will have a large effect on how well you can use an LDAP Directory. Here are a few examples. The LDAP search filters can be simple to very complex logical expressions. This is an area that you want to concentrate on as it will have a large effect on how well you can use an LDAP Directory. Here are a few examples.

26. DEV-4: OpenEdge in an LDAP World Agenda Introduction to LDAP Directory Service fundamentals Exploring the LDAP API LDAP Authentication Process Using LDAP from the ABL language

27. DEV-4: OpenEdge in an LDAP World LDAP User Authentication DN Nobody types in their full DN�uid=alice,ou=doc,ou=people,ou=us,o=acme corp� LDAP authentication code finds the user�s full DN for them Search for the user�s entry where the login-id matches one, or more, of the entry�s attribute value login-id LDAP search filter alice �(uid=alice)� alice smith �(cn=alice smith)� asmith �(sAMAccountName=asmith)� One of the most common questions regarding using LDAP for user authentication is �does the user have to type in their fully qualified DN?�. The answer is no. Look at Windows Active directory. Each user account login uses a fully qualified user DN, but the users enter only their simple user-id information. The answer is that the LDAP client code uses the simple user-id information and uses it to do an LDAP search for the user�s account. From that account, it can get the user�s full DN and use it along with the user�s password to do the actual authentication operation. There are multiple ways of specifying simple login information via directory attributes. The organization may choose to allow one or more of them. Examples may include using a �uid�, �commonName�, or an AD SAM account name. One of the most common questions regarding using LDAP for user authentication is �does the user have to type in their fully qualified DN?�. The answer is no. Look at Windows Active directory. Each user account login uses a fully qualified user DN, but the users enter only their simple user-id information. The answer is that the LDAP client code uses the simple user-id information and uses it to do an LDAP search for the user�s account. From that account, it can get the user�s full DN and use it along with the user�s password to do the actual authentication operation. There are multiple ways of specifying simple login information via directory attributes. The organization may choose to allow one or more of them. Examples may include using a �uid�, �commonName�, or an AD SAM account name.

28. DEV-4: OpenEdge in an LDAP World User-id prompt�s value used in LDAP search for user�s full DN  Can allow multiple forms of login-ids, each a different user object attribute  example: uid, cn, or e-mail Building LDAP Search Filters You will need to build the LDAP search filter on each user authentication. Depending upon the configuration you need to use for the company, it may be as simple as matching a simple �people� user account entry that has a �uid� attribute. Other companies may want to allow a user to use more than one form of user-identity. Your template for that type of LDAP search would include a �person� user account object� that has one of �uid�, �commonName�, or �mail� (e-mail). These simple templates can be optional configuration parameters and the REPLACE function works nicely for filling in the user-id information. You will need to build the LDAP search filter on each user authentication. Depending upon the configuration you need to use for the company, it may be as simple as matching a simple �people� user account entry that has a �uid� attribute. Other companies may want to allow a user to use more than one form of user-identity. Your template for that type of LDAP search would include a �person� user account object� that has one of �uid�, �commonName�, or �mail� (e-mail). These simple templates can be optional configuration parameters and the REPLACE function works nicely for filling in the user-id information.

29. DEV-4: OpenEdge in an LDAP World LDAP Authentication Process After you have configured the LDAP session�s servers and options, the first major decision point is how to �bind� to the Directory. That decision is based on whether the LDAP administrator allows the default �Anonymous� account to search the directory or whether a specific user-DN and password is required. You should allow for specifying a fully qualified search user-DN and password in case it is needed. After you have configured the LDAP session�s servers and options, the first major decision point is how to �bind� to the Directory. That decision is based on whether the LDAP administrator allows the default �Anonymous� account to search the directory or whether a specific user-DN and password is required. You should allow for specifying a fully qualified search user-DN and password in case it is needed.

30. DEV-4: OpenEdge in an LDAP World LDAP Authentication Process One you have bound to the Directory Service, you search build the LDAP search filter using the user�s login identity. Then perform a sub-tree search for the user�s account. Do no return the entry�s attributes at this time, just because you can search and find an entry does not mean that you can read any of its attributes. If the LDAP search returns entries, ensure that exactly one entry is returned. Otherwise you have ambiguous user identification. Save the user entry�s full DN for the next steps and unbind from the directory. One you have bound to the Directory Service, you search build the LDAP search filter using the user�s login identity. Then perform a sub-tree search for the user�s account. Do no return the entry�s attributes at this time, just because you can search and find an entry does not mean that you can read any of its attributes. If the LDAP search returns entries, ensure that exactly one entry is returned. Otherwise you have ambiguous user identification. Save the user entry�s full DN for the next steps and unbind from the directory.

31. DEV-4: OpenEdge in an LDAP World LDAP Authentication Process You now have the user�s full LDAP DN and the password they have entered. You can now do that actual LDAP user authentication by re-binding to the directory with that DN and user entered password. Your application may, or may not, use the LDAP user�s account information. If you don�t and require administrators to re-enter it to your application, you probably will not be their most popular people. If you do want to take advantage of the LDAP user account and/or role information you are now bound to the Directory with the security privileges required to load that account�s attributes. So do another LDAP search of the search-root only and have the search return the user�s attributes. The attributes to return may be the entire list, or some subset that your application requests. I let the full list of attributes be returned and allow a configuration parameter optionally specify a specific list. You now have the user�s full LDAP DN and the password they have entered. You can now do that actual LDAP user authentication by re-binding to the directory with that DN and user entered password. Your application may, or may not, use the LDAP user�s account information. If you don�t and require administrators to re-enter it to your application, you probably will not be their most popular people. If you do want to take advantage of the LDAP user account and/or role information you are now bound to the Directory with the security privileges required to load that account�s attributes. So do another LDAP search of the search-root only and have the search return the user�s attributes. The attributes to return may be the entire list, or some subset that your application requests. I let the full list of attributes be returned and allow a configuration parameter optionally specify a specific list.

32. DEV-4: OpenEdge in an LDAP World LDAP Authentication Process Because user authentication to LDAP may take some time, you do not want to re-authenticate and load user account information on each user context switch in your application. Instead, you will probably want to cache it to reload quickly. Because user authentication to LDAP may take some time, you do not want to re-authenticate and load user account information on each user context switch in your application. Instead, you will probably want to cache it to reload quickly.

33. DEV-4: OpenEdge in an LDAP World Agenda Introduction to LDAP Directory Service fundamentals Exploring the LDAP API LDAP Authentication Process Using LDAP from the ABL language

34. DEV-4: OpenEdge in an LDAP World Use OS Native LDAP Shared Libraries All vendors support common LDAP options Identify and conditionalize vendor specific options Option support is relative to the Directory Service, not the LDAP client Find the operating system�s LDAP shared library Solaris: /usr/lib/libldap.so Windows: wldap32.dll Linux: /usr/lib/libldap.so HPUX: Mozilla / OpenLDAP / Internet Express AIX: OpenLDAP* I remind you again, that not all LDAP options are supported by every vendor. You have to be adaptive to the Directory Service server�s configuration. I�ve included a list of where you can find, or get, LDAP API native libraries for your application. I remind you again, that not all LDAP options are supported by every vendor. You have to be adaptive to the Directory Service server�s configuration. I�ve included a list of where you can find, or get, LDAP API native libraries for your application.

35. DEV-4: OpenEdge in an LDAP World Working With a Native Shared Library Use a MEMPTR variable (mNULL) Set iPtrSize to hardware�s address size (4 or 8 bytes) Fill MEMPTR with zeros define variable mNULL as MEMPTR no-undo. define variable iPtrSize as INTEGER INITIAL 4 no-undo. set-size(mNULL) = iPtrSize. do i = 1 to iPtrSize: put-byte(mNULL, i) = 0. Pass mNULL as INPUT parameter to LDAP function One of the items I found for working with the LDAP api was the use of the �C� language NULL memory address pointers. There are certainly other ways to do this, but I use a MEMPTR the size of the OS�s address and initialize it to all zeros. Always works for me. One of the items I found for working with the LDAP api was the use of the �C� language NULL memory address pointers. There are certainly other ways to do this, but I use a MEMPTR the size of the OS�s address and initialize it to all zeros. Always works for me.

36. DEV-4: OpenEdge in an LDAP World Working With a Native Shared Library Extracting attribute value memory-pointers returned from ldap_search() ldap_get_values(� , OUTPUT mAttrValues).iPtrIndex = 1.for i = 1 to iNumValues do: if (iPtrSize = 4) then do: set-pointer-value(mValue) = get-long(iPtrIndex, mAttrValues). end. else do: set-pointer-value(mValue) = get-int64(iPtrIndex, mAttrValues). end.  iPtrIndex = iPtrIndex + iPtrSize. cAttrValue = get-string(mValue,1).end. The other thing that was interesting was the return of an entry�s attribute values as a �C� language array. Many of the LDAP attributes are character strings and what is returned is an array of character-string address pointers. Here is a code fragment that outlines how to access a multi-valued character-string attribute. The other thing that was interesting was the return of an entry�s attribute values as a �C� language array. Many of the LDAP attributes are character strings and what is returned is an array of character-string address pointers. Here is a code fragment that outlines how to access a multi-valued character-string attribute.

37. DEV-4: OpenEdge in an LDAP World In Summary LDAP is a popular choice for managing distributed network services Used often as a single-point of user authentication LDAP support is achievable from the OpenEdge ABL

38. DEV-4: OpenEdge in an LDAP World For More Information, go to� PSDN White paper: LDAP User Authentication in an OpenEdge ABL Environment Internet references: www.openldap.org msdn.microsoft.com docs.sun.com www.iana.org/assignments www.alvestrand.no/objectid/ Reference books: LDAP Programming Directory-Enabled Applications with Lightweight Directory Access Protocol Check out the full sample code and white paper on PSDN. Check out the full sample code and white paper on PSDN.

39. DEV-4: OpenEdge in an LDAP World Relevant Exchange Sessions DB-14: OpenEdge Database Run-time Security Revealed DB-19: OpenEdge Authentication without the _User Table DB-8: Jump-starting Your OpenEdge Auditing Solution ARCH-4: A Statefull Application in a Stateless World These are some other related sessions what will complement your new LDAP Directory knowledge. These are some other related sessions what will complement your new LDAP Directory knowledge.

40. DEV-4: OpenEdge in an LDAP World

41. DEV-4: OpenEdge in an LDAP World

42. DEV-4: OpenEdge in an LDAP World LDAP API Session Functions (Binding)

43. DEV-4: OpenEdge in an LDAP World LDAP API Search Functions

44. DEV-4: OpenEdge in an LDAP World LDAP API Entry Functions

45. DEV-4: OpenEdge in an LDAP World LDAP API Attribute Functions

46. DEV-4: OpenEdge in an LDAP World LDAP API Attribute Value Functions

47. DEV-4: OpenEdge in an LDAP World LDAP API Session Function (Unbinding)

48. DEV-4: OpenEdge in an LDAP World Error Handling

49. DEV-4: OpenEdge in an LDAP World LDAP API Session API Parameters ldap_set_option : LDAP-Option conform to production�s configuration LDAP_OPT_AREC_EXCLUSIVE [0x98] LDAP_OPT_SSL [0x0a] LDAP_OPT_TIMELIMIT [0x04] LDAP_OPT_PROTOCOL_VERSION* [0x11] ldap_set_option : Option-Value for setting & discovering configuration values LDAP_OPT_ON [0x01] LDAP_OPT_OFF [0x00] LDAP_VERSION3* [0x03] There are some primary operations that will need to have configuration parameters or are required operations. The first thing that needs to happen is to initialize the LDAP API library. In this you can specify multiple LDAP Directory Service hosts so that the library can do fail-over if the primary is not available. After initialization, you set the network protocol options such as DNS record types, using SSL, timeouts and especially the LDAP protocol version which must be �v3�. Common option values are logical ON/OFF, and I�ve added the value for the required version 3 LDAP wire protocol. There are some primary operations that will need to have configuration parameters or are required operations. The first thing that needs to happen is to initialize the LDAP API library. In this you can specify multiple LDAP Directory Service hosts so that the library can do fail-over if the primary is not available. After initialization, you set the network protocol options such as DNS record types, using SSL, timeouts and especially the LDAP protocol version which must be �v3�. Common option values are logical ON/OFF, and I�ve added the value for the required version 3 LDAP wire protocol.