DESIGN DESCRIPTION

Mentata LDAPHttp Framework

2. System design

Constraints

Directory object classes represented by LDAPHttp objects must each have an indexed and accessible name attribute and unique identifier attribute; these can be the same field. Entries corresponding to an object may reside in a node or a subtree of the directory hierarchy, but the location must be unambiguously defined per object. If LDAP authentication is used, the system also expects a single location for user accounts. The LDAPHttp framework is focuses on textual data, and does not currently support binary attributes. The gateway design focuses on the server side, minimizing the use of client technologies such as Java Applets and Javascript that may be unsupported in some browsers.

Components

The following paragraphs describe the general building blocks for a typical system implementing LDAPHttp.

Services

The LDAPHttp framework centers around three common internet services defined through open standards.

Directory server

Some or all persistent data used in an LDAPHttp system would be stored behind a Lightweight Directory Access Protocol (LDAP) compliant directory server. The protocol defines mechanisms for searching and manipulating data over the network. Directory servers also typically host user accounts and the protocol can handle authentication while servers evaluate potentially complex access control logic against these identities.

Servlet container

The Java servlet specification defines the standard mechanism for instantiating server-side Java internet applications. With LDAPHttp, servlets and JavaServer Page (JSP) content hosted by a servlet engine performs by proxy all explicit interaction with the directory server, generates the dynamic content of a system, and manages session state.

Web server

The front end for an LDAPHttp system would typically be web server instances that host both static content and connections to servlet containers. Web servers provide a mechanism for stateless client/server interaction for end users with browsers. Web servers can frequently be configured to authenticate against directory servers to establish identity and rights in their own access control facilities.

Data

Although it is entirely possible for LDAPHttp applications to use data from any source, this section refers specifically to data that would be stored behind directory servers.

Directory database

A directory database can be stored in a variety of systems, including an RDBMS, although the directory data model is generally more object oriented than relational. A directory database is essentially a collection of entries organized hierarchically with each entry uniquely identified by its location in the resulting data tree. An entry represents a collection of attributes, each of which may store one or more values.

Schema

The structure of each entry in a directory database conforms to a schema, where directory object classes and attributes are defined. An attribute amounts to a field name, a syntax type, and an indication for single or multivalue storage. An object class is a named set of required and optional attributes. As with object oriented programming languages, object classes and attributes can be defined in a hierarchy where one builds on the definition of another by extension. Directory servers are delivered with several standard schema elements and ordinarily provide a mechanism for adding custom object classes and attributes.

Accounts

An account in a directory server is an entry with the associated attributes and authority to represent a person or role. In any transaction with a directory server, a requesting agent can submit authentication credentials and thereby bind to the directory with the identity of the account. Access control rules for a directory may be defined in terms of these identities, enabling complex strategies for assigning data privileges and roles.

Indices

Directory indices are used to speed up search operations on attributes. They can be configured for explicit matches, substring matches, or the existence of values. Any attribute that will be used in a search should be appropriately indexed for optimal speed.

Applications

LDAPHttp applications are written as Java and best deployed as collections of web application archive (.war) files loaded onto the servlet container service.

Libraries

Three open source Java libraries form the basis for all LDAPHttp applications. In implementation, they may be contained within a system’s web application archives or available in the servlet container’s shared class path.

JLDAP

A subset of classes from the open source JLDAP libraries are used extensively in the LDAPHttp framework. Of particular significance, the connection class is used for all direct communication with the directory server, the entry class is used to encapsulate search results, and the exception class is used to identify server errors.

L3D

L3D is an acronym for LDAP in 3 dimensions: contexts, objects, and attributes. This library provides the fundamental abstractions for the LDAPHttp framework, although it can also be used alone for simple client applications.

SG8

SG8 is an acronym for servlet gateway. The SG8 library extends the context, object, and attribute classes of the L3D package to create web-based directory applications with basic data management functionality. The framework operates on a single sign-on (SSO) model that leverages session management.

Contexts

Locally defined properties files called contexts contain all necessary configuration information about the directory server, database, and environment. The properties are parsed and manifest in memory as a concrete instance of an SG8 and/or L3D context Java class which disburses all connections to the directory server and all LDAPHttp objects.

Objects

In LDAPHttp, objects refer to SG8 and/or L3D Java classes that represent template containers corresponding to a chain of one or more object classes in the directory schema along with a location in the directory hierarchy. Objects provide methods for searching or characterizing entries that match their definition, and can also be populated with the data for an entry by copying stored values in corresponding attribute instances assigned to the object. Populated objects can then be used to express the data, derive new information, or manipulate the entries they represent. An object can be further customized by overriding default behaviors or adding new ones. The framework is delivered with initial definitions for some standard LDAP object classes.

Attributes

LDAPHttp attributes are SG8 and/or L3D Java classes stored within an LDAPHttp object which can correlate to relevant attributes from the directory schema or can be analogous containers for values generated at runtime. Classes to support a variety of attribute types are delivered with the framework to accommodate various forms of data values or associations. It is also straightforward to define custom attribute types with their own select behaviors.

Labels

Each LDAPHttp object or attribute can be assigned a textual label for use in interfaces. Labels for an object can also be parsed as a set from a localized properties file.

Servlets

The SG8 package includes servlets for retrieving, creating, deleting, updating, and linking directory entries. Servlet URIs matching an intuitive grammar can serve as entry points into the gateway functions, actions on specific entries, or complete catalogues.

JSP

The framework employs JavaServer Page (JSP) content for all dynamic responses to servlet requests. Default JSP content is delivered with the framework, but may be altered or overridden per context or object with custom versions of designated pages. The standard servlets store objects and result sets in session scoped beans for transfer to JSP.

Tags

Complex functionality is implemented in JSP through libraries of additional tags. The default JSP content uses elements from the Standard Tag Library as well as tags from an SG8 specific library. Custom JSP can use these or additional tag libraries as desired.

Static content

It is not necessary to have any static content in an LDAPHttp system, but it is useful in enhancing the appearance and cohesion of applications.

Includes

LDAPHttp contexts or objects can be configured to include files of HTML or JSP content from the enclosing web application archive to serve as headers and footers in associated web page responses.

Styles

LDAPHttp contexts or objects can be configured to apply the display characteristics of a Cascading Style Sheet (CSS) from the enclosing web application archive in associated web page responses.

HTML

The gateway servlets can be invoked from static HTML forms or hyperlink references in HTML content.

Images

Image files can be referenced by a particular LDAPHttp attribute type, but typically would reside behind a web server instead of inside a directory database.

Clients

LDAPHttp is web based, so the typical client would be a browser. However, through the parent L3D API, the framework also supports the reuse of contexts, objects, and attributes to interface directly with LDAP servers without a need for containers or HTTP servers.

Operation

While it is not unreasonable to implement LDAPHttp on a single machine, the HTTP, LDAP, and servlet container services can be hosted on separate machines, and there could be several of each for reasons including redundancy and distributed computing.

Architecture

The following diagram illustrates an assembled system in the most basic topology.

The color coding indicates the partitioning of the framework into the traditional roles of the Model-View-Controller (MVC) paradigm.

Model

The information, abstractions, and domain-specific logic of an LDAPHttp system are entirely encapsulated in the directory database and the LDAPHttp objects and attributes of the applications. Since directories, Java, and LDAPHttp are all object oriented and hierarchical, the organization of this intellectual capital is intuitively organic, consistently codified, and readily transferable. Applications can even be internationalized without changing their structure.

View

Virtually everything an LDAPHttp end user would see is web content expressed in file formats familiar to graphic designers and compatible with common editing tools. The look and feel of the applications is thoroughly customizable, and the features can be easily shared between objects, contexts, or even disparate applications. LDAPHttp is designed to seamlessly integrate with other web content so that the presentation is limited only by the internet itself.

Controller

The heart of the framework is a central stack of time-tested services, each implemented by a plethora of vendors with highly regarded open source alternatives. The complexity and administration load for the architecture is relatively low, the requisite skills are common, and the software costs range from cheap to nothing. Simple contexts are the only configuration files specific to LDAPHttp that must be defined by the implementing enterprise to make it all work together.

Flow

In the gateway, application level processes start with a request to a servlet. The servlets can be called from either static URLs or HTML forms, depending on the nature of their action. The servlets process incoming request parameters and make use of shared resources to accomplish their action and provide web based feedback. In some cases servlets chain by redirecting their output to one another, by generating links to each other, or by forwarding session scoped data to JSP content. The servlet container performs all protocol level communication and may share pools of connections to the directory server.

In the course of completing their tasks, the servlets instantiate an example of a specified object as defined under a specified context. Each example object serves as a template, with predefined behaviors and data placeholders. The template can be populated with actual data from one or more entries in the directory database and elements of data can be manipulated, but the structure of the object template or the configuration of a context cannot be redefined from within a servlet. Additional objects may also be used by the servlet to represent related entry data. Relevant objects and data are encapsulated in Java beans and passed via the session to JSP content, which is used to generate all forms and responses delivered back to the client browser.

Security

Connections from browser to HTTP server as well as from container to LDAP server can be encrypted. A system may use separate entry points for public access and for internal data management, whereby the public front end is unencrypted and non-authenticating while the internal entry point would use encryption in all exchanges. At the initiation of application requests that imply privilege, users are first automatically prompted for userid and password credentials. From that point on, valid user sessions are tracked through the standard servlet API. A connection to the directory server bound with the associated identity is stored with the session in memory and used in all subsequent directory transactions. Users do not need to enter their credentials again until their session expires, and in the default JSP content are consistently offered a link to end their authoritative session manually.

The directory server would verify credentials however it is configured to do so; most directory offerings provide several options that can range from simple to robustly secure. The directory itself may be configured with access control rules that limit data modification privileges to designated users, while the application interface may further constrain what users are enabled to do. IP based access control filtering, firewalling, or web content restrictions can be used to prevent direct access to the directory service or select application interfaces from external clients.

Roles

Deploying LDAPHttp applications can be accomplished by a single skilled engineer, but could also require many individuals to fill a variety of roles.

System administrators

Installation and maintenance of an LDAPHttp framework implementation requires at least one experienced information professional to administer the hardware, operating systems, network configurations, and requisite web, directory, and Java services. Additional responsibilities would likely include backup of the system and database, bulk data loading, log file management, and system monitoring. These administrators would typically work from a command line with superuser or equivalent access to the systems they manage, but would not necessarily need accounts in any directory servers.

Application developers

Any use of the LDAPHttp framework necessitates the coding, compiling, and packaging of Java software. While the most straightforward use of the framework can be easy for a naive developer, more complex custom functionality is better served by software engineers with a deeper knowledge of Java. Programmers would produce Java class files for LDAPHttp objects, custom attributes, or new functions, and likely also maintain the properties files for LDAPHttp contexts and labels. Since LDAPHttp is open source, developers will also have access to all of the underlying source code for the framework, providing deeper insight into its workings and opportunities to make revisions as necessary.

Data administrators

Using the data manipulation actions of the servlet gateway, specialized groups of people with appropriate domain knowledge can manage the directory data. These individuals would be granted directory accounts and granular privileges to data through appropriate access control rules defined in the directory implementation. They may also make use of L3D Java clients that reuse context, object, and attribute definitions to manipulate data in batch, command-line processes.

Users

A user may be any person that uses the web interfaces of the LDAPHttp framework to visualize or manipulate directory data. They may or may not have directory accounts, depending on the sensitivity of the data and the privileges associated with their actions.