1.7 Programming Interfaces for eDirectory

With the first release of NDS, application developers could access NDS through a set of C-interface functions. These functions were available on the server for NLM applications and on Novell clients for client applications.

Soon after NDS version 5.73 shipped, Novell made LDAP Services for NDS available. This product made the NDS database accessible by LDAP-compatible applications, such as browsers and Web servers.

1.7.1 NDAP and LDAP Interfaces to NDS

With NDS versions 7.xx and 8.xx, NDS became accessible through multiple interfaces. The following figure illustrates how NDS is accessible through two protocols (NDAP and LDAP) and which interfaces use which protocol.

Figure 1-2 NDS Programming Interfaces

These interfaces are available for NDS clients of NDS on NetWare, Solaris, and NT. Only NetWare supports a server-side interface for NLM development.

For developers that prefer scripting, NDS has the following interfaces:

  • JavaBeans. This interface is a set of high-level abstractions of Java code that are packaged as functional, reusable components that can be run on any platform. The Beans for Novell Services and eCommerce Beans allow applications to use eDirectory for management, authentication, and access control.

  • ActiveX. This interface is used by many visual programming tools such as Visual Basic and Delphi. The Novell Controls for ActiveX allow you to log in and out of the NDS tree, to read, write, and modify information in the NDS tree, and to access the NDS schema so that you can create new attributes for existing objects and for new objects. Two versions of the directory control are available: one through NDAP and one through LDAP.

  • ODBC. The ODBC Driver for eDirectory is a driver that enables SQL (Structured Query Language) to access NDS using visual programming tools such as Visual Basic and Delphi. The ODBC Driver for eDirectory allows you to use standard database utilities for reporting, graphing, and charting NDS information. It is a read-only driver.

  • NetBasic. This interface allows applications to access NDS through a Visual Basic script-compatible language called NetBasic. Novell NetBasic 6 allows you to build custom scripts to handle NDS administrative tasks.

  • Novell Script. Novell Script for NetWare (NSN) incorporates predefined NetWare components with a VBScript syntax-compatible scripting language. NSN provides a unified scripting and component architecture. The UCS (Unified Component System) kernel allows you to write solutions using and combining NSN components, JavaBeans, Perl scripts, and other popular scripting and component languages.

  • JDBC. The Novell JDBC Driver for NDS is a Java Database Connectivity driver that enables Java programs to execute SQL (Structured Query Language) statements to access NDS. JDBC is similar to ODBC, but it has been designed to work specifically with Java programs and used LDAP to access eDirectory.

For developers who prefer object oriented programming, the following interfaces are available:

  • LDAP Classes for Java. This interface allows access to NDS over an LDAP client rather than a Novell client. It supports all the standard LDAP functions for LDAP v3 as well as LDAP extensions for managing naming contexts (NDS replicas and partitions). For secure authentication, it currently uses SSL (Secure Socket Layer).

  • JNDI. The Java Naming and Directory Interface is an addition to JavaSoft's Enterprise API set and provides an easier way within Java to discover network resources. JNDI allows you to access NDS objects, partitions, and schema using LDAP.

  • ConsoleOne. Novell ConsoleOne is a Java-based framework or shell with APIs for creating network management utilities, or snap-ins. All aspects of NDS are accessible, making it possible for you to access NDS easily and efficiently as you create a management snap-in for your NDS application.

For C programmers, the following interfaces are available:

  • NDS Libraries for C. This interface allows access to all the features of NDS: read, write, and modify NDS object and attribute information; schema extensions; and partition and replica management. The functions are available for the development of both NDS client dlls and NDS server applications.

  • LDAP Libraries for C. This interface allows access to NDS over an LDAP client rather than a Novell client. It supports all the standard LDAP functions for LDAP v3 as well as LDAP extensions for managing naming contexts (NDS replicas and partitions). For secure authentication, it currently uses SSL (Secure Socket Layer) or SASL (Secure Authentication Security Layer).

For additional information on, and access to, these interfaces, see the Novell Developer Kit.

1.7.2 Compatibility Criteria for NDAP Applications

For NDAP applications to pass the compatibility criteria for NDS, the applications must meet the following standards.

  • Installation. You must be able to install the application in any container. The application's install utility must only require ADMIN rights. It must not require the user to log in is as ADMIN.

  • Bindery. The application must not use bindery calls. NDS applications must use DS naming conventions exclusively.

  • Searches. The application must not perform unlimited scope searches of the entire NDS tree; instead it should limit searches to segments of the tree. Searching the entire tree causes unacceptable degradation of NDS performance

  • Compare versus Read. Whenever possible, the application must use a compare API in place of a read API. This ensures that you are not forcing a reference to the main NDS tree and adversely affecting the performance of NDS. A local reference to a local replica is much faster.

  • Polling Objects. The application must not poll NDS objects. A registered event must be used to signal an attribute change. Polling has a negative effect on performance.

  • Schema Extensions and Objects. You must registered with Novell to obtain a prefix and ASN.1 ID for your extensions.The names must use the prefix and conform to LDAP naming conventions.The NDS object class definitions and directory objects created by your application must be referenced and used by your application.

  • Duplicate Information. The application must not duplicate information already stored in NDS (for example, create and maintain its own list of user objects). It is better to leverage the data that already exists, which will improve the performance of your application and NDS.

  • Authentication. The application must authenticate exclusively through NDS. The application must not save NDS passwords or leave passwords in memory for any length of time.

  • Security. The application should not create any back doors that enable access to the applications' supervisory rights without logging in. The application's objects should not pose any security threat to the system.

  • Objects at the Root. The application must not create or use an object at the root of the tree that might cause security issues, network administration difficulties, or inconvenience to users that have insufficient rights to the root of the NDS tree This must be accomplished without reducing the security level of the NDS root or employing object-specific security rights at the root of the tree.

1.7.3 Compatibility Criteria for LDAP Applications

For LDAP applications to pass the compatibility criteria for NDS, the applications must meet the following standards.

  • Installation. You must be able to install the application in any container. The application's install utility must only require ADMIN rights. It must not require the user to log in is as ADMIN.

  • Schema Extensions and Objects. You must registered with Novell to obtain a prefix and ASN.1 ID for your extensions.The names must use the prefix and conform to LDAP naming conventions.The schema definitions and entries created by your application must be referenced and used by your application.

  • Mapping. If your application supports releases of NDS previous to NDS eDirectory (8.2x), your application's installation program must either map the schema extensions to NDS classes and attributes or you must provide detailed documentation that instructs the system administrator how to perform the mappings manually.

  • LDAP Extensions and Controls. Your application must use only LDAP extensions and controls that are compliant with LDAP v3 specifications.

  • Polling Objects. Your application should not poll NDS objects for changes. Polling has a negative effect on NDS performance.If you cannot eliminate the need for polling, do it infrequently and allow the system administrator to set the polling interval.

  • Duplicate Information. Your application must not duplicate information already stored in NDS (for example, create and maintain its own list of user objects). It is better to leverage the data that already exists, which will improve the performance of your application and NDS.

  • Internationalization. Your application must use UTF8 for message tables, which provide compatibility with language support for users world-wide. This support is required even if your messages are in English.

  • Security. Your application should not create any back doors that enable access to the applications' supervisory rights without logging in. The application's objects should not pose any security threat to the system.

  • Objects at the Root. Your application must not create or use an object at the root of the tree that might cause security issues, network administration difficulties, or inconvenience to users that have insufficient rights to the root of the NDS tree This must be accomplished without reducing the security level of the NDS root or employing object-specific security rights at the root of the tree.

  • Authentication. Your application must use secure connections. It cannot authenticate using clear text passwords. The application must not save NDS passwords or leave passwords in memory for any length of time.

For more information about NDS Test Tools, see Novell Software Test Tools