|Sun Java(TM) System Directory Proxy Server 5.2 2005Q1 Administration Guide|
Overview of Directory Proxy Server
This chapter introduces you to Directory Proxy Server. The chapter consists of the following sections:
Directory Proxy Server is an essential component of any mission-critical directory service for e-commerce solutions. Directory Proxy Server is an LDAP application layer protocol gateway that offers enhanced directory access control, schema compatibility, and high availability using application layer load balancing and fail over.
Functionally, Directory Proxy Server is an "LDAP access router" located between LDAP clients and LDAP directory servers. Requests from LDAP clients can be filtered and routed to LDAP directory servers based on rules defined in the Directory Proxy Server configuration. Results from the directory server can be filtered and passed back to clients, again based on rules defined in the Directory Proxy Server configuration. This process is totally transparent to the LDAP clients, which connect to Directory Proxy Server just as they would to any LDAP directory server.
Directory Proxy Server is a unique product that provides high availability, security, and client compatibility features for both extranet and intranet directory infrastructures, including:
Directory Proxy Server coexists with and complements new and existing LDAP directory infrastructures and integrates seamlessly with directory-enabled applications already deployed in enterprise extranets and intranets. It can be deployed to leverage the existing investment in a customer's directory infrastructure. Directory Proxy Server will inter-operate with any LDAP compliant directory server. Directory Proxy Server will work with any LDAP enabled and conformant directory, whether it's a native LDAP directory, an LDAP enabled X.500 directory, or an LDAP enabled relational database.
Directory Proxy Server implements the LDAPv3 Internet specification and also supports the older and less functional LDAPv2 specification for compatibility with already deployed directory-enabled client applications that use LDAPv2. Directory Proxy Server runs as a separate system server process on UNIX platforms. The server is multi-threaded and can handle thousands of LDAP client requests while applying access control rules and protocol filtering rules to each request.
Directory Proxy Server can help organizations protect their private directory information from unauthorized access, while making it safe for these organizations to publish their public information. Directory Proxy Server can be used to configure a fine-grained, access control policy on LDAP directories, such as controlling who can perform different types of operations on different parts of the Directory Information Tree (DIT). Directory Proxy Server can also be configured to disallow certain kinds of operations typically performed by web trawlers and robots to collect information.
Unlike a web proxy server, Directory Proxy Server operates in a reverse proxy mode. It does not forward connections to arbitrary servers on the Internet from clients inside the firewall. Neither does it cache search results. The predominant reason for this is the problem of applying access controls to the data. This is currently done only in the LDAP directory server where the access controls are maintained. Directory Proxy Server has no knowledge of the directory server access controls.
Directory Proxy Server Feature Set
The Directory Proxy Server feature set provides distinct functions: high availability, load balancing, fail over, firewall-like security, and client-server compatibility.
Directory Proxy Server is designed to support high availability directory deployments by providing both automatic load balancing and automatic fail over and fail back among a set of replicated LDAP directory servers. For extranet and intranet environments it is often necessary to ensure that mission-critical directory-enabled clients and applications have 24x7 access to directory data. Directory Proxy Server maintains connection state information for all directory servers that it knows about, and is able to dynamically perform proportional load balancing of LDAP operations across a set of configured directory servers. Should one or more directory servers become unavailable, the load is proportionally redistributed among the remaining servers. When a directory server comes back on line, the load is proportionally reallocated dynamically.
For example, suppose directory server A is configured to receive 40 percent of the LDAP client load, server B 20 percent, server C 20 percent and server D 20 percent. If directory server B fails, Directory Proxy Server will recognize that server A is configured to carry twice the load of servers C and D, and will redistribute the 20 percent load from server B such that server A now receives 50 percent, server C 25 percent and server D 25 percent. When directory server B is recovered, Directory Proxy Server will automatically detect this and revert back to the original load percentages configured across all four servers.
Network layer IP load balancing devices don't have access to the LDAP protocol layer. However, Directory Proxy Server integrates load balancing with access control, query filtering, and query routing, and can make intelligent application layer access control and LDAP routing decisions.
Load balancing must be configured in Directory Proxy Server using the load balancing property described in Defining and Managing Property Objects. Each back-end directory server that Directory Proxy Server can communicate with is configured to receive a percentage of total client load. Directory Proxy Server then automatically distributes client queries to different back-end servers to meet the load criteria defined in the configuration. If a server becomes unavailable, Directory Proxy Server distributes the load percentage of that server proportionally among the available servers based on their load percentage. Directory Proxy Server starts rejecting client queries if all back-end LDAP servers become unavailable.
Load balancing in Directory Proxy Server is session-based. This means that the decision function that chooses a particular server to which a client's queries will be directed is applied once per client session; in particular, at the start of the client session. All subsequent client queries in that session are directed to the server that was chosen at the beginning of the session.
The number of back-end LDAP servers that Directory Proxy Server can load balance depends on several factors, such as the size of the host running Directory Proxy Server, the network bandwidth available, the query mix that Directory Proxy Server receives, the length of client sessions, and Directory Proxy Server's configuration. In general, Directory Proxy Server can support fewer servers if most sessions are short lived and queries are computationally intensive. Computationally intensive queries are those that require the inspection of the entire message such as when the attribute renaming feature described in Attribute Renaming Property is used.
Directory Proxy Server uses a monitor process to make health checks on its backend servers including those that communicate only through SSL. This feature is automatically enabled if load balancing is used. Directory Proxy Server makes an anonymous search operation for the Root DSE every 10 seconds for each of its backend directory servers. If one of them becomes unavailable or unresponsive, Directory Proxy Server removes it for the active load balanced server set. When the server becomes available again, it is reintroduced in the set.
Directory Proxy Server detects when a server becomes unavailable either when a connection attempt is returned with a connection refused error or when it times out. Since both these cases occur at the initial stages of the session, and no operations have yet been processed for that session, Directory Proxy Server fails over to another server, provided one is available transparently. In the connect attempt timeout case, the client can experience significant delay in getting a response. If a connection between Directory Proxy Server and a back-end server is abruptly lost, Directory Proxy Server returns LDAP_BUSY error for all outstanding operations to the affected client. Subsequently, Directory Proxy Server fails over that client session to another directory server.
In order to avoid Directory Proxy Server becoming the single point of failure for your directory deployment, we recommend you use at least two Directory Proxy Servers with an IP appliance in front of it.
Directory Proxy Server provides flexible external directory access control facilities that enhance the basic access control provided by a directory server. The access control mechanisms allow different users and communities of users to be associated with specific access groups to which administrator-defined security restrictions and query filters will be applied. The administrator can control access to entries based on LDAP authentication information, IP address, domain name, and other criteria.
A significant security feature that Directory Proxy Server provides is the protection of the number of connections established between LDAP clients and the LDAP directory server. You can protect your LDAP directory server from connection attacks by configuring Directory Proxy Server to monitor a number of specific metrics: the number of simultaneous client operations, the number of operations a client can request per connection, and the number of connections for a particular client group. It also has the ability to time out inactive clients.
You can configure Directory Proxy Server with specific threshold limits not to be exceeded for the given metrics. Directory Proxy Server will monitor these metrics and ensure that the thresholds are not exceeded. Directory Proxy Server keeps several metrics, such as the number of connections open from a particular host, the number of operations performed on a particular session, etc., to limit possible trawling of the directory and denial of service attacks. A detailed description of the configuration of these parameters are in Creating System Configuration Instances.
Directory Proxy Server also limits trawling by disallowing certain kind of generic filter such as (cn=A*) or (cn>A). More details on how to configure filtering of filters is in Creating and Managing Groups."
Directory Proxy Server allows an authenticated client to change its access control to the directory service. This allows authenticated clients to have greater access to the directory information even if they are outside the secure network.
Directory Proxy Server provides data protection by supporting Secure Socket Layer (SSL) transport protocol. You can, for example, configure Directory Proxy Server so that all clients that access your directory services from outside the protected network are required to establish an SSL session. Details on configuring SSL in Directory Proxy Server is given in Configuring Security.
These features can help prevent "denial of service" attacks and "flood attacks" that are so commonplace in the industry today. If Directory Proxy Server detects that a threshold has been reached, it will then start refusing connections to the directory server and prevent the directory server from being attacked and overwhelmed.
Directory Proxy Server makes query routing decisions based on LDAP Distinguished Names (DNs) and group access rights, including identifying mobile users based on authentication credentials. Directory Proxy Server automatically follows LDAP referrals that may be returned by a directory server, in support of highly distributed and scalable directory services. Automatic referral following is a significant advantage for large-scale directory deployments where you must physically distribute directory information among a set of directory servers, but have the distributed directory appear to users as one logical directory. Directory Proxy Server supports this type of deployment scenario by providing the ability to logically unify otherwise distributed directory data in support of scalable distributed directory services.
Directory Proxy Server supports any compliant LDAPv2 or LDAPv3 client application. Support is provided for schema rewriting to accommodate client applications with fixed schemas that do not always match the directory server's schema. For example, the Microsoft Outlook email client has a fixed schema that expects the directory server to implement Microsoft-defined attributes that may not match an enterprise's more general schema requirements. The schema rewriting capability allows the directory system administrator to implement a general purpose enterprise schema, and then map specific elements of that schema dynamically into the set of attribute types that are required by the less functional client application. Directory Proxy Server is otherwise schema agnostic and accepts any attribute types and object classes defined by a large set of standard and ad hoc industry schema definitions, including RFC1274, X.520, X.521, LIPS, PKIX, inetOrgPerson, and DEN.