System, method and computer program product for authenticating users using a lightweight directory access protocol (LDAP) directory server

A system, method and computer program product for providing authentication to a firewall using a lightweight directory access protocol (LDAP) directory server is disclosed. The firewall can be configured through a graphical user interface to implement an authentication scheme. The authentication scheme is based upon a determination of whether at least part of one or more LDAP entries satisfy an authorization filter.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to user authentication mechanisms and more particularly to user authentication mechanisms for firewalls.

2. Related Art

Control over access to information technology (IT) resources is a common need today. A firewall can be used to protect IT resources behind the firewall. Network firewalls can enforce a site's security policy by controlling the flow of traffic between two or more networks. For example, a company might encourage file transfers to the company's network that assist employees, but might discourage file transfers of potentially sensitive company confidential information from the company network to external destinations. Firewalls often are placed between a corporate network and an external network such as, e.g., the Internet, or a partnering company's network. Firewalls can also be used to segment parts of a corporate network. A firewall system can provide both a perimeter defense to, e.g., an internal network, and a control point for monitoring access to and from specific networks such as, e.g., an external network.

Firewalls can control access at a network level, an application level, or both. At the network level, a firewall can restrict packet flow based on protocol attributes. For example, the packet's source address, destination address, originating transmission control protocol/user datagram protocol (TCP/UDP) port, destination port, and protocol type can be used for the control decisions. At an application level, a firewall can participate in communications between the source and destination applications with the firewall's control decisions being based on details of the conversation and other available information such as, e.g., previous connectivity or user identification. Thus, a firewall can authenticate users to control access to and from IT resources behind and before the firewall.

Firewalls can be packaged as system software, combined hardware and software, and, more recently, dedicated hardware appliances (e.g., embedded in routers, or easy-to-configure integrated hardware and software packages that can run on dedicated platforms). An example of an application-based firewall is the Gauntlet™ firewall available from Network Associates, Inc.

Firewalls can defend against attacks ranging from, e.g., unauthorized access, IP address “spoofing” (i.e., a technique by which hackers disguise traffic as coming from a trusted address to gain access to a protected network or resource), buffer overrun attacks, session hijacking, viruses and rogue applets, and rerouting of traffic. However, inherent limitations exist in certain services and protocols that conventional firewalls cannot remedy.

Conventionally, when software application programs sought to restrict what a user could do with the programs, the programs required identification of the user. For example, if a user desires access to sensitive corporate financial data in an accounting program, access to the data can be restricted by means of authentication mechanisms such as, e.g., a password. The application program therefore requires a list of users and identification information for the user for use in authenticating the user.

Early software application programs often included their own integrated authentication mechanisms. Users often use a variety of software application programs, each possibly having its own authentication mechanism. Users find it cumbersome to remember different passwords associated with each of the multiple software application programs.

IT resources used by companies today can include access to multiple software application programs and Internet based applications. For example, employees at a given company can use e-mail and groupware applications, and other office automation programs including, e.g., to spreadsheets, wordprocessors and presentation programs. As every application program conventionally has its own authentication mechanism, a separate database is initialized and updated for each application.

Authentication mechanisms can use a query to a database known as a directory that can store information about users. A directory is similar to a database in that one can store information in a directory and later retrieve the information from it. However, a directory is specialized in that a directory is typically designed for reading more than writing. A directory offers a static view of the information and allows simple updates without transactions. Thus, while a database is typically written to and read from frequently, a directory by comparison is primarily read from and is infrequently updated.

A directory service includes all the functions of a directory and adds a network protocol that can be used to access the directory. Standardization is desirable in implementing a directory service.

An early standard for directory service was the directory access protocol (DAP), which originated in the European standards organization. DAP although specifying a vast, feature-rich protocol for storing and encoding directory information, was unwieldy in size.

Today, a new protocol, lightweight directory access protocol (LDAP), is gaining wide acceptance in business. The LDAP standard defines an information model for a directory, a namespace for defining how directory information is referenced and organized, and a network protocol for accessing information in the directory. LDAP can also include an application programming interface (API). The LDAP protocol mandates how client and server computers can communicate with a LDAP directory. However, LDAP does not mandate how data should be stored. More and more companies today use an LDAP directory server to store a database of employees. The LDAP directory generally can store an employee name, phone number, address and other information about the employee, and a password for modifying the employee's information.

Firewalls also maintain a database of users and are operative to prompt users for an identifying user identifier and password. These conventional firewalls require that employee names and passwords be entered into a firewall authentication database. Maintenance of the firewall authentication database is especially burdensome where there are a large number of employees that are frequently leaving or joining a company or when a company has a large number of firewalls. Accordingly, what is needed is a mechanism for reducing this administrative burden. More specifically, what is needed is a mechanism for leveraging an existing LDAP directory server as part of a firewall's authentication process. In this manner, an existing LDAP directory server can be used as a central directory that stores the data used by all applications.

SUMMARY OF THE INVENTION

A system, method and computer program product for enabling the authentication of users to a firewall using a lightweight directory access protocol (LDAP) directory server is provided by the present invention. The firewall can be configured through a graphical user interface to implement an authentication scheme. The authentication scheme is based upon a determination of whether information contained in one or more LDAP entries satisfy an authorization filter. It is a feature of the present invention that the authentication scheme can be configured independently of specifically stated field requirements or schema of the firewall. In accordance with the present invention, the authentication scheme can be flexibly specified to interact with a LDAP directory that has been uniquely developed for a company's internal needs. The company's investment in its existing administrative infrastructure can therefore be leveraged to a greater degree.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1illustrates an example embodiment of a communications network100including client computers102aand102bcoupled via an internal network104to an internal server computer106and a firewall110. Communications network100also includes a client computer102ccoupled via an internal network112to firewall110. Finally, communications network100includes client computers116aand116bcoupled via an external network114to an external server computer118and firewall110. External network114can represent, e.g., the Global Internet, or a partnering company's network.

Network firewall110can enforce a business' security policy by controlling the flow of traffic between two or more networks such as, e.g., internal networks104and112and external network114. In general, firewall110serves to isolate internal networks104and112from one another and also from external network114.

As illustrated inFIG. 1, firewall110can be used to segment parts of a corporate network. For example, firewall110can be used to control information flow between a corporation's internal networks104,112. Firewall110can also provide a perimeter defense between an internal network104,112and an external network114.

FIG. 2illustrates an example embodiment of a communications network200that includes client computer102acoupled via internal network104to internal server106and to firewall210. Firewall210is also coupled via external network114to external server118.

As shown, client computer102aincludes a browser202. Browser202can in one embodiment be an Internet browser that provides a graphical user interface to network resources. Browser202is generally operative to parse and make requests to network resources such as, e.g., external server118, and present the results of the request to a client user viewing client computer102a.

Internal server106is shown including a lightweight directory access protocol (LDAP) directory204, which can be configured to store employee information. For example, a human resources database could be stored as an LDAP directory having a directory structure such as that illustrated inFIG. 4. As illustrated, LDAP directory tree400includes country402set in this example to US, organization404set to NAI, location406set to Rockville and location408set to Santa Clara, department410set to engineering and department412set to sales, and username414set to amullican and username416set to jgraham.

External server118can include an Internet server application. In one embodiment, the Internet server application supports file transfer protocol (FTP) communication. As would be apparent to those skilled in the relevant art, other types of server applications can be included on external server118including, e.g., databases, and electronic mail.

Firewall210is shown including an authorization module206. Authorization module206is used to authenticate a client user (e.g., client computer102a) to determine if the client user's communication is authorized to pass through firewall210. Conventional firewalls110included their own database having a list of users and passwords, to enable authentication through firewall110.

In accordance with the present invention, firewall210does not authenticate users using its own database. Rather, firewall210authenticates users using information contained within LDAP directory204. As will be described in greater detail below, firewall210can authenticate users through an authentication scheme that can be based upon the unique composition of an organization's LDAP directory204.

It is a feature of the present invention that the authentication scheme of the present invention can operate independently of specifically stated field requirements or schema of the firewall210. In other words, an organization's LDAP directory204need not be modified to conform to a schema imposed by the firewall210. Moreover, resistance to such a modification will not result in the maintenance of multiple directories.

In accordance with the present invention, the authentication scheme can be flexibly specified to interact with an existing LDAP directory that has been uniquely developed for a organization's internal needs. This framework enables a firewall administrator to seamlessly integrate a firewall product into an existing administrative infrastructure. The organization's investment in the existing administrative infrastructure can therefore be leveraged to a greater degree.

FIG. 3illustrates the authentication process that is implemented by firewall210. In the illustrated example, firewall210authenticates a client user at client computer102arunning a browser202that is attempting to access an application or resource on external server118. This access path is illustrated by path302.

This authentication process begins when client computer102ainitiates a network resource request304from browser202. The network resource request304is intercepted by firewall210. Authorization module206within firewall210challenges the client user to identify himself or herself. A challenge could in one embodiment include a request for entry of a username and password. Upon receipt of the identification information, authorization module206searches an authentication database (not shown) to identify an authentication method (e.g., LDAP authentication). If no entry in the authentication database is found for the client user, then a default authentication method can be used. In the LDAP authentication process, authorization module206binds to LDAP directory204and uses the userPassword attribute for authentication.

After authorization module206authenticates the client user, authorization module206then determines whether the client user is authorized to have his access request fulfilled. The LDAP authorization process is illustrated as communications306and308. Communications306and308are facilitated using the LDAP protocol and may utilize the secure sockets layer.

If per-user authorization is configured, authorization module206determines whether one or more attributes of the client user's LDAP entry satisfies an authorization filter. If the one or more attributes of the client user's LDAP entry does not satisfy the authorization filter, then authorization module206determines that the authorization fails. If the authorization filter is satisfied, then the client user's network resource request is allowed through firewall210. This allowed connection is illustrated inFIG. 3as path310.

To support per-user authorization, an administrator configures an authorization filter to use when authenticating users. One or more attributes in the client user's LDAP directory entry and associated values can be selected for the authorization filter. Once configured, authorization module206can verify that the LDAP entry used in the bind call satisfies the authorization filter before allowing the user access to/through the firewall.

FIG. 5illustrates an example embodiment of a graphical user interface (GUI)500of a firewall systems administrator application screen. As shown by a selected radio button, LDAP authentication502has been selected. GUI500includes a primary LDAP server settings area510, a secondary LDAP server settings area520, an authentication settings area530, and a per-user authorization settings area540.

The primary LDAP server settings area510includes a host field512and a port field514. The host field512can be used to enter an IP address or host name of a primary LDAP server. The port field514can be used to enter the port to be used on the primary LDAP server.

The secondary LDAP server settings area520also includes a host field522and a port field524. The host field522can be used to enter an IP address or host name of a secondary LDAP server. The port field524is used to enter the port to be used on the secondary LDAP server. Fields522,524can be left blank if no secondary LDAP server is being used.

The authentication settings area530, can include searchbase field532and a username attribute field534. The searchbase field532can be used to indicate the top of the directory tree400such as, e.g., country402, organization404, location406, and department410, so that a lookup can be within that portion of the directory tree. For example, a set of attribute pairs such as, e.g., o=NAI, c=US to append to all requests to the LDAP server can be entered. The username attribute field534can include a default username attribute such as, e.g., uid. The username attribute field534can be used in performing per-user authorization.

The per-user authorization settings area540includes a search filter field542and a timeout field544. The timeout field544can include a default value such as, e.g., 60 seconds. For example, timeout field544can be used to limit the amount of time the authorization filter query can take. If the time is exceeded, the authorization fails.

The search filter field542is used by firewall210in identifying the appropriate fields that are the subject of the LDAP directory authentication query. Upon receipt of a response from the LDAP directory204, firewall210can then determine whether the client user is authorized to authenticate through the firewall210.

In general, the authorization filter can contain any LDAP-valid combination of attributes and values, including object classes. At its simplest, the authorization filter specifies a single attribute and value pair. For example, the search filter field542can be used to enter a search filter expression such as “objectclass=gauntletUser.”

Consider another example where LDAP directory204is configured by the company to include a field that would provide an access code level for each user. For example a “1” could correspond to only e-mail access, while a 5 could mean full access to all Internet services including world wide web browsing. In this environment, an authorization filter can be specified as “(&(objectclass=gUser)(status>=5))”.

It should be noted that the authorization process need not be based on per-user authorization. In another embodiment, the authorization process can be based on a per-service authorization. In this embodiment, the per-service authorization can include an authorization for protocol services. Examples of protocol services include FTP, simple mail transport protocol (SMTP) e-mail, hypertext transport protocol (HTTP), etc. The per-service authorization can also be based on LDAP directory information. For example, authorization module206can use group memberships to determine whether a client user can use HTTP through firewall210. To satisfy this authorization process, the authenticated user must be a member of the “web-users” group in the LDAP directory.

In one embodiment, the per-service authorization process uses the standard groupOfNames and groupOfUniqueNames object classes for authorization decisions. In general, a mechanism can be included that supports the specification of arbitrary group names for each service to be controlled. Control can then be based on a per-proxy basis or a per-policy basis.

Specification of per-service authorization criteria can also be implemented using the search filter field542. In general, a different search (or authorization) filter can be provided for each service. For example, a search filter field can be included in GUI500to determine whether, e.g., a user is authorized to perform a file transfer, to send e-mail, or to access the world wide web. A search filter field can also be included in GUI500to determine whether, e.g., a user is a member of a particular group such as, e.g., engineering department410, and if so, then particular services can be authorized based on being part of that group.

As noted, it is a feature of the present invention that firewall210can support arbitrary LDAP directory schema. Accordingly, firewall210does not require additional firewall-specific object classes or attributes in the directory. Customers can populate the LDAP directories with whatever data they require. This authentication environment can be flexibly applied across multiple organizations each having their own sets of directory information. Indeed, the concepts of the present invention can be used to implement an authorization filter that relies on portions of information that are stored in distinct LDAP directories. This distributed authentication scheme enables an organization to implement segmented management of the user database.