Methods and apparatuses for providing improved directory services

A method, apparatus and computer program product are provided for implementing an improved directory services system. An example of the method includes transmitting an access request to a directory services server, the access request comprising user credentials, receiving, in response to validation of the user credentials by the directory services server, a directory services response from the directory services server, the directory services response comprising one or more fields of directory services data generated by the directory services server, translating the directory services response to generate a generic data object, wherein the generic data object comprises one or more values derived from the one or more fields of directory service data included in the directory services response, and providing the generic data object to an application.

TECHNOLOGICAL FIELD

Example embodiments of the present invention relate generally to methods, systems, and computer readable storage media for implementing directory services and, more particularly, to methods, systems, and computer readable media for generating data objects from lightweight directory access protocol responses.

BACKGROUND

The Lightweight Directory Access Protocol (LDAP) is an open industry standard for accessing directory information services over Internet Protocol networks. LDAP is often used to provide a centralized repository of login information so as to facilitate access to various applications and services. However, although LDAP is a recognized standard, the implementation of this standard often varies significantly across different networks and systems. In order for applications to interface with LDAP servers, each application must be aware of the particular format, structure, and content of messages for that particular LDAP implementation. Accordingly, a disproportionate amount of time may be spent developing interfaces for communication with LDAP servers, and updating or modifying such an interface typically requires editing of the application code that implements the interface to the LDAP server.

Through applied effort, ingenuity, and innovation, Applicant has solved many of these identified problems by developing a technical solution that is embodied by the present invention, which is described in detail below.

BRIEF SUMMARY

Methods, apparatuses and computer program products are therefore provided according to example embodiments of the present invention in order to provide improved directory access operations through the use of a configurable LDAP translator. The LDAP translator is operable to receive a response from an LDAP server, and generate one or more generic data objects (e.g., Plain Old Java® Objects or “POJOs”) which may be stored or transmitted for use by the application that initiates an access request. By formatting the LDAP response in a generic data object, embodiments obviate the need to understand the entire structure and format of the LDAP response message. Furthermore, the ability of the LDAP translator to be configured (e.g., by one or more configuration files) allows for additions and editing to reflect changes in the LDAP response structure without the need to rebuild or otherwise edit applications making the access request. Such an LDAP translator may also be used in systems that implement two or more LDAP response structures, in the event an application or applications need to communicate with LDAP servers that have different response structures.

An example of an embodiment of a method for implementing improved directory services in a computer network includes transmitting an access request to a directory services server, the access request comprising user credentials, receiving, in response to validation of the user credentials by the directory services server, a directory services response from the directory services server, the directory services response comprising one or more fields of directory services data generated by the directory services server, translating the directory services response to generate a generic data object, wherein the generic data object comprises one or more values derived from the one or more fields of directory service data included in the directory services response, and providing the generic data object to an application.

The application may also generate the access request. The directory services server may be implemented according to the Lightweight Directory Access Protocol (LDAP) standard and the directory services response may be an LDAP response. Translating the directory services response may include receiving one or more configuration files, the one or more configuration files comprising a definition of the generic data object, identifiers for one or more of the fields of directory service data, and one or more rules for formatting the one or more fields of the directory service data for storage in the generic data object, identifying the one or more values derived from the one or more fields of the directory service data based on the identifiers for the one or more fields of directory service data, and formatting the identified one or more values for storage in the generic data object based on the one or more rules. The configuration file may include values encoded in a Yet Another Markup Language (YAML) format. The generic data object may be a Plain Old Java Object. The method may include storing the generic data object in a database. At least one field of the directory services response may not be included in the generic data object.

An example of an embodiment of an apparatus for implementing improved directory services in a computer network includes a processor coupled to a memory. Instructions stored within the memory configure the processor to at least transmit an access request to a directory services server, the access request comprising user credentials, receive, in response to validation of the user credentials by the directory services server, a directory services response from the directory services server, the directory services response comprising one or more fields of directory services data generated by the directory services server, translate the directory services response to generate a generic data object, wherein the generic data object comprises one or more values derived from the one or more fields of directory service data included in the directory services response, and provide the generic data object to an application.

The application may also generate the access request. The directory services server may be implemented according to the Lightweight Directory Access Protocol (LDAP) standard and the directory services response may be an LDAP response. Translating the directory services response may also include receiving one or more configuration files, the one or more configuration files comprising a definition of the generic data object, identifiers for one or more of the fields of directory service data, and one or more rules for formatting the one or more fields of the directory service data for storage in the generic data object, identifying the one or more values derived from the one or more fields of the directory service data based on the identifiers for the one or more fields of directory service data, and formatting the identified one or more values for storage in the generic data object based on the one or more rules. The configuration file includes values encoded in a Yet Another Markup Language (YAML) format. The generic data object may be a Plain Old Java Object. The processor may be further configured to store the generic data object in a database. At least one field of the directory services response may not be included in the generic data object.

An example of an embodiment of a non-transitory computer readable storage medium includes instructions that, when executed by a processor, cause the processor to implement improved directory services in a computer network. The instructions cause the processor to at least transmit an access request to a directory services server, the access request comprising user credentials, receive, in response to validation of the user credentials by the directory services server, a directory services response from the directory services server, the directory services response comprising one or more fields of directory services data generated by the directory services server, translate the directory services response to generate a generic data object, wherein the generic data object comprises one or more values derived from the one or more fields of directory service data included in the directory services response, and provide the generic data object to an application.

The application may also generate the access request. The directory services server may be implemented according to the Lightweight Directory Access Protocol (LDAP) standard and the directory services response may be an LDAP response. The instructions may further configure the processor to translate the directory services response by at least receiving one or more configuration files, the one or more configuration files comprising a definition of the generic data object, identifiers for one or more of the fields of directory service data, and one or more rules for formatting the one or more fields of the directory service data for storage in the generic data object, identifying the one or more values derived from the one or more fields of the directory service data based on the identifiers for the one or more fields of directory service data, and formatting the identified one or more values for storage in the generic data object based on the one or more rules.

DETAILED DESCRIPTION

Introduction and Definitions

A method, apparatus and computer program product are provided in accordance with example embodiments of the present invention to provide improved directory services for networked computing environments. As noted above, the inventors have identified that present systems for providing directory services are inadequate for many use cases due to tight coupling between directory services server message structures and application directory service access interfaces. To address these problems, the inventors have developed methods and systems that provide a translation layer between directory services servers and applications, such that directory services responses (e.g., Lightweight Directory Access Protocol Responses) received from servers are translated into generic data objects, such as Plain Old Java Objects (POJOs) such that the application does not need to know the particular message structure employed by the directory services server.

Furthermore, the inventors have recognized that the use of a configurable translator allows for changes and additions to the structure of the directory services response without the need to change the interface within the application. To this end, the translator may access one or more configuration files to identify fields and values within the directory services response for inclusion in the generic data object provided to the application. In the event new fields or values are configured on the directory services server, the configuration file may be updated to add those additional values to the generic data object generated by the translator application.

The inventors have also recognized that the use of an intermediate translation layer may also allow for allowing different applications to interact with the directory services response in different ways. For example, different applications may be concerned with different fields of the directory services response, such that different generic data objects are output depending upon which application makes the request to the directory services server.

As a result of utilizing embodiments of the present invention, applications requesting information from a directory services server do not require an understanding of the structure and contents of the directory services response. This provides the benefit of a streamlined implementation of such directory services systems with these applications, as developers merely need to configure their software to receive standard generic data objects, such as POJOs. Embodiments further provide the technical benefit of simpler data access by eliminating the need to implement parsing of the directory services response within the application itself, and by implementing a reduced representation of the directory services response (e.g., only selecting a subset of available fields), the application may access particular data fields which are relevant to its processing while discarding irrelevant fields, thereby improving performance and reducing the required memory footprint.

For the purposes of this disclosure, the term “directory services” refers to a network implementation of a protocol for accessing and maintaining distributed directory information services over a network. The use of this term further contemplates such directory services that, while conforming to a particular standard, such as the Lightweight Directory Access Protocol (LDAP) standard, particular response messages may contain a variety of data fields and data values that differ across implementations of the standard. For the purposes of this application then, the term “directory services” should be understood to cover networks implementing the LDAP standard and other equivalent standards such that said equivalent standards would function in a similar manner when used with embodiments of the invention as described herein. The term “directory services server” refers to a server module, apparatus, or application that is capable of providing directory services as described herein. For example, as contemplated by this application, an LDAP server would be a “directory services server.” It should also be appreciated that while many of the instant embodiments are described with particular reference to the LDAP standard, various alternative embodiments may utilize different standards or other directory services interfaces having similar structural or functional characteristics.

For the purposes of this disclosure, the term “directory services response” refers to a response received from a directory services server after a successful validation, such as in response to a username and password being accepted by the directory services server.

For the purposes of this disclosure, the term “generic data object” refers to a data structure that includes a set of values and methods for accessing those values. For example, embodiments may employ the use of POJOs as generic data objects.

Exemplary Client Apparatus

FIG. 1illustrates a block diagram of an apparatus100in accordance with some example embodiments. The apparatus100may be any computing device capable of implementing an interface with a directory services server and providing translation functions for directory services responses as described herein. For example, the apparatus100may be implemented as a client device implementing an application that requests directory services information from a central directory services server, such as an LDAP server. The apparatus100may execute login functionality to verify a user's credentials (e.g., user name and password) and receive a set of directory services information (e.g., single sign-on information, lists of subscribers, email addresses, network configuration information for that user, or the like). The apparatus100also implements a translation layer that serves to generate a generic data object from the directory services response to streamline the interaction between the application that executed the directory services request and the directory services server.

In some embodiments, such as where the apparatus is a client device, the apparatus100may include a display and input devices (e.g., mice, keyboards, touch screens, etc.) for providing an interface (e.g., a login screen, application window, or the like), while in other embodiments, such as where the apparatus100is an intermediate device, the apparatus100may function as an intermediate server providing the graphical user interface to another apparatus which in turn functions as a client device (e.g., where the apparatus provides remote access capabilities such as over a network). It should be appreciated that embodiments include scenarios both where the apparatus functions to generate a directory services request for a locally executing application (e.g., where the apparatus is a client device) or a remotely executing application (e.g., where the apparatus is an intermediate device), and while the apparatus is generally described as locally executing the application that initiated the directory services request, embodiments may also include scenarios where the application is executed external to the apparatus100.

The apparatus100may be implemented as a standalone or rack-mounted server, a desktop computer, a laptop computer, a personal digital assistant, a tablet computer, a netbook computer, a mobile device, or the like. Accordingly, it will be appreciated that the apparatus100may comprise devices, hardware, and the like configured to implement and/or otherwise support implementation of various example embodiments described herein.

It should be noted that the components, devices or elements illustrated in and described with respect toFIG. 1below may not be mandatory and thus some may be omitted in certain embodiments. Additionally, some embodiments may include further or different components, devices or elements beyond those illustrated in and described with respect toFIG. 1.

As illustrated inFIG. 1, an apparatus100may include a processor102, a memory104, input/output circuitry106, communications circuitry108, LDAP interface circuitry110, LDAP translator circuitry112, and generic object consumption circuitry114. The apparatus100may be configured to execute the operations described below with respect toFIGS. 2-4. Although these components102-114are described with respect to functional limitations, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components102-114may include similar or common hardware. For example, two sets of circuitry may both leverage use of the same processor, network interface, storage medium, or the like to perform their associated functions, such that duplicate hardware is not required for each set of circuitry. The use of the term “circuitry” as used herein with respect to components of the apparatus should therefore be understood to include particular hardware configured to perform the functions associated with the particular circuitry as described herein.

The term “circuitry” should be understood broadly to include hardware and, in some embodiments, software for configuring the hardware. For example, “circuitry” includes processing circuitry, storage media, network interfaces, input/output devices, and/or the like. In some embodiments, other elements of the apparatus100may provide or supplement the functionality of particular circuitry. For example, the processor102may provide processing functionality, the memory104may provide storage functionality, the communications circuitry108may provide network interface functionality, and the like, such that each of the circuitries may be formed by other circuitry components of the apparatus100.

In some embodiments, the processor102(and/or co-processor or any other processing circuitry assisting or otherwise associated with the processor) may be in communication with the memory104via a bus for passing information among components of the apparatus. The memory104may be non-transitory and may include, for example, one or more volatile and/or non-volatile memories. In other words, for example, the memory may be an electronic storage device (e.g., a computer readable storage medium). The memory104may be configured to store information, data, content, applications, instructions, tables, data structures, or the like, for enabling the apparatus to carry out various functions in accordance with example embodiments of the present invention.

The processor102may include various processing devices and may, for example, include one or more processing devices configured to perform independently from one another. Additionally or alternatively, the processor may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining, and/or multithreading. The use of the term “processing circuitry” may be understood to include a single core processor, a multi-core processor, multiple processors internal to the apparatus, and/or remote or “cloud” processors.

In an example embodiment, the processor102may be configured to execute instructions stored in the memory104or otherwise accessible to the processor. Alternatively or additionally, the processor may be configured to execute hard-coded functionality. As such, whether configured by hardware or software methods, or by a combination thereof, the processor may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present invention while configured accordingly. Alternatively, as another example, when the processor is embodied as an executor of software instructions, and the instructions may specifically configure the processor to perform the algorithms and/or operations described herein when the instructions are executed.

The communications circuitry108may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device, circuitry, or module in communication with the apparatus100. In this regard, the communications circuitry108may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the communications circuitry108may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and/or software, or any other device suitable for enabling communications via a network. Additionally or alternatively, the communication interface may include the circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to handle receipt of signals received via the antenna(s).

The LDAP interface circuitry110includes hardware configured to interact with an LDAP server to perform directory services operations, such as transmission of user credentials to the LDAP server and receiving of a directory services response from the LDAP server. The LDAP interface circuitry110utilizes network interface hardware, such as the communications circuitry108, to transmit the user credentials to the directory services server and to receive a directory services response from the directory services server in response to the directory services server validating the user credentials. The LDAP interface circuitry110may interact with the generic object consumption circuitry114such that the generic object consumption circuitry114provides an application interface or interfaces including a login screen. In some embodiments, a framework, such as Spring Security, may facilitate the interaction between the generic object consumption circuitry and the LDAP interface circuitry110. An LDAP response received by the LDAP interface circuitry110may be transmitted to the LDAP translator circuitry112via a shared memory, bus, application programming interface (API) call, or other mechanism for transmission of such data. The LDAP response may be provided to the LDAP translator circuitry112in the same format or structure as the LDAP response was provided by the directory services server. An example of a data interaction between a directory services server and an embodiment of an LDAP interface is described further below with respect toFIG. 2.

The LDAP translator circuitry112includes hardware configured to translate an LDAP response received from an LDAP server via the LDAP interface circuitry110to generate a generic data object (e.g., a POJO) from the LDAP response. The LDAP translator circuitry112may receive the LDAP response from the LDAP interface circuitry110via a message bus, shared memory, API call, or the like implemented on hardware, such as the processor102. The LDAP response is received by the LDAP translator circuitry112in the same format or structure as it was transmitted by the directory services server. The LDAP translator circuitry112generates a generic data object in a format suitable for consumption by the generic object consumption circuitry114, extracting one or more data values from the LDAP response according to the configuration of the LDAP translator circuitry112. The LDAP translator circuitry112may be configured by one or more configuration files which identify particular fields of the LDAP response for extraction and storage in the generic data object. The LDAP translator circuitry112may implement particular methods and functions for such generation of data objects, including functionality for instantiating such objects, allocating memory, and interacting with those objects (e.g., getter and setter functions, and other methods associated with the generic data objects). An example of a data flow for generating a generic data object from an LDAP response using an LDAP translator is described further below with respect toFIG. 2. A specific embodiment of a method for translating an LDAP response to generate a generic data object is described further below with respect toFIG. 4.

The generic object consumption circuitry114includes hardware configured to receive, store, utilize, or otherwise consume a generic data object generated by the LDAP translator circuitry112to include one or more data values received in an LDAP response received by the LDAP interface circuitry110. The generic object consumption circuitry114may include, for example, an application configured to provide a login interface and to receive directory services information in response to a successful login operation. Rather than receive and parse an LDAP response resulting from such an interaction, the generic object consumption circuitry114instead receives the generic data object in a format that includes methods and functions for accessing the relevant data included in the generic data object by the LDAP translator circuitry112. Such an implementation advantageously reduces the amount of data received by the generic object consumption circuitry and provides an efficient, flexible interface for accessing that data. This implementation also eliminates the need for the application or applications that wish to receive the LDAP response to include functions or other code to parse the structure of the LDAP response or communicate directly with the LDAP server. The generic object consumption circuitry114may, in some embodiments, include a database for storing the resulting generic data objects produced by the LDAP translator circuitry112for later use, while in other embodiments the generic data objects may be used immediately to obtain needed directory services data. The generic object consumption circuitry114may include processing hardware, such as the processor102, and storage capability, such as the memory104to perform these and other functions related to utilizing the generic data object that includes the directory services data. It should be appreciated that the various uses of this data may include network configuration, performing of a “single sign-on” such that the application is provided with credentials to access multiple remote systems, or various other uses in conformance with the manner in which LDAP responses are otherwise implemented, without the functions and methods for parsing those LDAP responses being implemented within the generic object consumption circuitry114or attendant applications themselves.

As will be appreciated, any such computer program instructions and/or other type of code may be loaded onto a computer, processor or other programmable apparatus's circuitry to produce a machine, such that the computer, processor other programmable circuitry that execute the code on the machine create the means for implementing various functions, including those described herein.

Having now described an apparatus configured to implement and/or support implementation of various example embodiments, features of several example embodiments will now be described. It will be appreciated that the following features are non-limiting examples of features provided by some example embodiments. Further, it will be appreciated that embodiments are contemplated within the scope of disclosure that implement various subsets or combinations of the features further described herein. Accordingly, it will be appreciated that some example embodiments may omit one or more of the following features and/or implement variations of one or more of the following features.

Examples of Improved Directory Services Data Flows

The following data flows describe example system interactions for providing improved directory services in accordance with embodiments of the present invention. The data flows illustrate interactions among system components to facilitate contacting a directory services server (e.g., an LDAP server), receiving a response, translating the response using a configurable translator to generate a generic data object, and providing the generic data object to an application that initiated the contact with the directory services server.

In the particular example illustrated inFIG. 2, a client202is in communication with an LDAP server204. The client202may be an apparatus as described above with respect toFIG. 1, such that the client includes hardware configured to execute the directory services access operations described herein. The client202includes an application206in communication with an LDAP interface208and an LDAP translator210. The application206may be implemented by or in conjunction with generic object consumption circuitry214as described above with respect toFIG. 1, the LDAP interface208may be implemented by or in conjunction with LDAP interface circuitry110as described above with respect toFIG. 1, and the LDAP translator210may be implemented by the LDAP translator circuitry112described above with respect toFIG. 1.

The application206may include any type of application that is operable to generate an access request to an LDAP server, such as the LDAP server204. For example, the application206may include an authentication or security component that provides a user name and password to the LDAP server204, and in response receives directory services information from the LDAP server204. As described above, embodiments of the present invention advantageously allow for improved applications that do not need to directly implement an LDAP interface for receiving and parsing an LDAP response, as such parsing and translation functions are handled by the LDAP translator210.

In the example data flow200, the application initiates an access request to the LDAP server204. This access request may, as noted above, include providing login credentials. The access request may be received via the LDAP interface208, and the LDAP interface may facilitate transmission of the access request to the LDAP server204as an LDAP request. In response to the LDAP request, the LDAP server204may validate the LDAP request (e.g., verify the login credentials), and generate an LDAP response for transmission back to the LDAP interface208. The LDAP response may be received by the LDAP interface208. After the LDAP interface208receives the LDAP response, the LDAP response may be sent directly to the LDAP translator210(as pictured), or returned to the application206. In embodiments where the LDAP response is returned to the application, the application206subsequently forwards the LDAP response to the LDAP translator210(not shown).

The LDAP translator210facilitates translation of the LDAP response into a generic data object. As described above, the structure and contents of the LDAP response vary depending upon the particular implementation of the LDAP server204, such that, in order to extract meaningful data from the LDAP response, the application would need to implement a specific method for parsing the LDAP response. Instead, embodiments implement the LDAP translator210to translate the LDAP response into a format suitable for consumption by the application. An example LDAP response for a fictional user “abc123xy” may be presented as follows:

While the LDAP response may define particular fields and corresponding values for the particular user, the exact structure of such an LDAP response often varies from one LDAP server to another.

The LDAP translator210may be configured in this process by a translator configuration file212. The translator configuration file212may include a definition of the generic data object214output by the LDAP translator210, and a set of rules for identifying relevant data fields of the LDAP response and extracting the content associated with those relevant fields for inclusion in the generic data object214.

For example, a translator configuration file212may define the generic data object as follows:

This data object may include each of the fields that is relevant to the particular application206. In some embodiments, different applications may be associated with different object definitions, such that each application only receives data that is relevant to that particular application. In other embodiments, the generic data object214may be defined in a single manner, with each field that is deemed to be relevant to any particular application that may initiate an access request. In the present example, the generic data object includes fields for a user's first name, last name, date of hire, particular access roles, a user ID, a password, an email address, a title, a department, an employee ID, and the like.

The translator configuration file212also includes a set of rules for reviewing the LDAP response and populating the generic data object with data from the LDAP response. For example, a set of rules included in a translator configuration file212for extracting the data referenced in Table 2 from the LDAP response referenced in Table 1 might be as follows:

As depicted in Table 3, the configuration file may represent the rules for translating the LDAP response in a markup language, such as Yet Another Markup Language (YAML). Types, value pairs, and formatting for data values may be represented through particular markup tags, and the translator may parse this markup language to configure the translation process. As noted in Table 3, some fields may also include parameters used for formatting those fields. For example, the “hireDate” field includes a parameter for formatting an associated date, “yyy-MM-dd”. It should be appreciated that different types of data fields may be associated with different types of parameters. For example, the “USER” and “ADMIN” values use a “common name” parameter as indicated by the “CN” parameter.

In some embodiments, the generic data object is populated with the information from the LDAP response through a process known as “Java Reflection.” The process of Java Reflection enables the mapping process to occur at runtime to populate the generic data object with data from the LDAP response in a flexible, efficient manner.

Upon receiving the LDAP response, the LDAP translator210may iterate through the fields of the LDAP response to determine which fields are identified within the translator configuration file212as relevant to the generic data object being created for consumption by the application206. As each field is encountered within the LDAP response, the corresponding data value is used to populate the corresponding values of the generic data object.

It should be appreciated that fields of the generic data object and the LDAP response may not have a one to one correlation. For example, the LDAP response may use a single field to define the user's name, “John Doe,” while the generic data object may have separate data fields for the user's first name and last name. The translator configuration file212may include rules for parsing such occurrences to merge or separate data fields as appropriate when generating the generic data object.

After generating the generic data object214, the generic data object214is provided to the application. In some embodiments, providing the generic data object214to the application includes storing the generic data object in a database or other local memory where it is accessible to the application (e.g., via a function call executed after receiving a notification of the success of the access request and/or translation operation), while in other embodiments the generic data object214is transmitted to the application directly (e.g., via a shared memory, bus, or the like). The application206may subsequently access the data stored within the generic data object214via methods associated with the generic data object214, as typically utilized in object-oriented paradigms.

Exemplary Processes for Implementing an Improved Directory Services Interface

FIGS. 3-4are flow diagrams depicting example processes for implementing an improved directory services interface in accordance with embodiments of the present invention. These processes may be employed by an apparatus, such as the apparatus100described above, to perform tasks related to creation of an access request from an application, receipt of an LDAP response from an LDAP server, translation of the LDAP response into a generic data object, and provision of the generic data object to an application. In this regard, these processes describe algorithms that are implemented via hardware or software executing on hardware components of an apparatus to implement these tasks and other tasks related to implementation of a directory services system. These algorithms may serve as means for implementing these tasks and other functions as described above and herein.

FIG. 3depicts an example of a process300for processing an access request made to a directory services server (e.g., an LDAP server), receiving an LDAP response, and generating a generic data object from the LDAP response. The process300may be performed, for example, by an LDAP interface208and/or LDAP interface circuitry110as described with respect toFIGS. 2 and 1, respectively. The process300therefore illustrates a mechanism by which different components of a client system interact to provide a requesting application or other generic object consumer with a generic object comprising data derived from an LDAP response.

At action302, an access request is received. As described above, the access request may include user account credentials, an identifier of a directory services server, and/or any other data necessary to request access to a set of directory services information from such a server. The access request may be generated, for example, by an application executing on a client. The access request may be related to a user account sign-on operation (e.g., access to a single system or service), a “single sign-on” operation whereby access is provided to multiple systems or services through a single access request, a request for a directory of users or addresses, or any other type of access request related to a request for directory services information from a directory services server.

At action304, the access request is transmitted to the directory services server. For example, the access request may be processed and formatted according to a particular standard, such as the LDAP standard, and transmitted to the directory services server via a network interface. At action306, a response is received from the directory services server, including information encoded in a particular format associated with that directory services server. The response may be generated by the directory services server in response to validating the user credentials or other information included in the access request. As noted above, the directory services response received from the directory services server may have a structure and contents that are unique to the particular implementation of the directory services server. To facilitate access to the data included in the response, the directory services response is translated into a generic data object.

At action308, particular data fields and other information within the directory services response are identified based on information stored within a configuration file. For example, the directory services response may be provided to a translator that is configurable by a configuration file that identifies particular fields of the directory services response and rules for translating those fields into a generic data object. At action310, those identified fields are used to generate the generic data object. An example of a process for identifying fields of the directory services response and generating the generic data object using those identified fields is described further with respect toFIG. 4.

At action312, the generic data object is stored and/or transmitted for use by the application that initiated the access request. As noted above, the generic data object may be provided directly to the application, or stored in a memory for accessing by the application at a later time. The generic data object may then be accessed by the calling application to obtain data relevant to that application for use in various functionality associated with directory services applications (e.g., identifying single sign-on information, identifying user/network configuration settings, identifying other user addresses, or the like).

FIG. 4depicts an example of a process400for translating a directory services response into a generic data object in accordance with embodiments of the present invention. As described above, embodiments employ a translator to facilitate the generation of such generic data objects, and the process400illustrates one embodiment whereby the translator is configurable to select particular data fields and values from a directory services response, and generate a generic data object using those selected data fields and values. The configuration of the translator is performed through the use of a configuration file or files which define the generic data object and identify the particular fields of the directory services response for inclusion in the generic data object. By using a configurable translator in this manner, the translator can be updated to reflect changes to the generic data object and/or directory services response through editing of the configuration file, rather than requiring recompilation of application source code to reflect the changes.

At action402, a configuration file or files is received. As noted above, in some embodiments multiple configuration files may be employed to represent different translation processes for different types of directory services responses. For example, if the translator supports requests made to two different directory services servers with different configurations (e.g., different data fields implemented by two different LDAP servers), then the particular configuration file chosen for use in translation may be keyed to the particular server address or directory services response type. As described above, the configuration file may include a definition of the generic data object to be output and a set of rules for identifying fields of the directory services response and converting the data values of those fields into elements of the generic data object.

At action404, the directory services response (e.g., an LDAP response) is received. As described above, the directory services response may be received in response to validation of user credentials included in an access request transmitted to the directory services server.

At action406, a field of the directory services response is selected. Selection of a field may be performed by tokenizing the directory services response (e.g., dividing the response up by the presence of particular characters or the like), each line of the directory services response may be understood to represent a different field, or various other techniques. In some embodiments, the LDAP response may be parsed using a particular library or external function. For example, some embodiments may employ the “Spring LDAP” library provided as a component of the “Spring Security” framework to parse through the directory entries, while other embodiments may utilize other parsing functions or processes to parse the LDAP response. After parsing the LDAP response, the particular fields identified in the configuration file may be searched for in the resulting parsed response. The parsed LDAP response may include definitions of fields and values included within the LDAP response, as the parsing process may separate fields and values from one another.

At action408, a determination is made as to whether the selected field is identified in the configuration file as a component of the generic data object. If the field is identified in the configuration file, the process proceeds to action410. Otherwise, the process proceeds to action412.

At action410, the process uses the rule associated with the particular data field to format the value of the field into the generic data object. As described above with respect to Table 3, the configuration file includes a rule or instructions for parsing the particular field and storing the attendant data in the generic data object. After storing the data in the generic data object, the process proceeds to action412.

At action412, a determination is made as to whether any data fields remain in the directory services response. If fields remain, the process returns to action406to select the next field, such that all fields of the directory services response are evaluated for inclusion in the generic data object. If no fields remain, the process proceeds to action414.

At action414, the process completes generation of the generic data object using the data identified when iterating through each field. Generation of the generic data object may include, for example, transmitting the generic data object and/or a memory location storing that generic data object to an application, or storing the generic data object in a database. It should also be appreciated that embodiments of the process400may also include initializing the generic data object with default values prior to reviewing the directory services response, such that the generic data object is initially generated, and then later populated with the data parsed from the directory services response.

Accordingly, blocks of the flowchart support combinations of means for performing the specified functions and combinations of operations. It will also be understood that one or more blocks of the flowchart, and combinations of blocks in the flowchart, can be implemented by special purpose hardware-based computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.