System Deployment
This chapter presents the conceptual information you need to design a successful DirX Access deployment. First, it contains a discussion of network topologies to help you plan your hardware requirements and software installations. Second, it contains a step-by-step guide for creating a security model that matches the needs of your organization and implementing that model within DirX Access.
Component Redundancy and Failover Techniques
Redundancy, load-balancing and failover schemes offer better performance, increased reliability, and the ability to meet service level agreements. DirX Access components can be installed in multiple locations on the network, and the DirX Access system fully supports redundant installations of other network components such as directory servers.
A typical network deployment plan for a small to medium-sized business is illustrated below, indicating some of the possibilities.
The first example of a failover mechanism in this network is the use of Web proxy servers. Proxy servers provide network access through a “farm” of Web servers, while hiding the addresses of the actual Web servers. Should any of the individual Web servers go down for maintenance, the proxy server can simply direct traffic through the remaining servers in the farm.
A special benefit of using a proxy server in the context of DirX Access is that policy enforcement points can be deployed on the proxy servers instead of on every one of the Web servers in the farm. This reduces the administration time required to install software components and maintain the network.
The proxy servers themselves are redundant in this example, with two separate instances, located on two separate hosts, providing access to the same farm of Web servers. Should either proxy go down, the other can continue to provide access until the first has recovered. Load balancing between the two proxy servers can be configured at the DNS level using a round-robin technique.
Each proxy server (or each Web server in the farm, if you choose that approach) runs a DirX Access PEP that intercepts requests for specified resources and connects to a policy decision point on a DirX Access server to determine user authorization. You can install multiple DirX Access servers on your network (four in the example above), and configure all PEPs to connect to the DirX Access servers cluster. When using the native communication protocol, the PEPs are capable of spreading the load to all reachable Servers in the cluster.
The final redundant component in this network is the directory server, which has primary and secondary instances containing the policy store used by all DirX Access PDPs. The fallback directory may be either another master directory or a replica that supports read and write operations.
For additional security, the DirX Access and directory servers in this sample network are shown in a separate zone, in a subnet protected by a firewall. The firewall opens only the IP addresses and ports necessary to communicate with the proxy servers and the application servers.
About the DirX Access Cluster
A DirX Access cluster is a set of DirX Access Servers configured by a single Application Repository and a set of DirX Access Cache Servers referenced by their configuration.
Contrary to the previous versions, the DirX Access Servers are not interconnected, rather, they connect as clients to the set of Cache Servers. This distribution improves the robustness of the system and simplifies the actions, such as updating, patching, and so on.
It is recommended to deploy one DirX Access Cache Server to each DirX Access Server to achieve high-availability and failover scenarios.
A cluster can be divided into one or more cluster groups, each of which shares its own internal state (for example, authenticated user sessions) via a distributed cache. Each cluster group is assigned its own number identifying it. Membership of a server in a corresponding cluster group can be easily configured via DirX Access Manager.
About the Cluster Resolution Mechanism
The cluster of DirX Access servers must be maintained with respect to the internal state integrity (e.g., existing authenticated sessions), high availability, etc. This is facilitated by a cluster resolution mechanism.
The following sections describe the mechanism and the necessary conditions on the overall system in which they are to be deployed.
Static Cluster Resolution
The Static Cluster Resolution mechanism is defined by three main features:
-
It does not need write access to the Application Repository.
-
When cluster segmentation occurs, the invalid part of the cluster is restarted at cluster reconnection.
-
All servers of the cluster must be defined before the cluster operational phase.
These features have the following reasons and implications:
Read-only Access to Application Repository
Access to the Application Repository is a necessary condition for proper operation of DirX Access. In scenarios where all configuration is known before the operational phase, access to the Application Repository can effectively be read-only. For the Static Cluster Resolution mechanism, read-only access is sufficient (as opposed to the Dynamic Resolution).
While it’s generally required to have write access to the Application Repository to enable any configuration changes (and some configurable scenarios require write access even for request-based actions), the ability of the Static Cluster Resolution to work with read-only access can be helpful when facing repository issues. If configured with DirX Directory deployed in Master-Shadow mode, when the Master is unreachable, the access mode switches automatically to read-only and, unlike the Dynamic Cluster Resolution, the Static Cluster Resolution mechanism still works properly.
Servers Restart
During the time of the disconnection within the cluster, all the servers are still operable. This, however, means that the cache holding the internal state (e.g., authenticated sessions) becomes different in each part of the disconnected cluster. Due to the use of the sticky-session mechanism, where the authenticated session (in a form of cookie) always determines the same server to be used for all its requests, the disconnected state works and all servers are running.
At cluster reconnection time, the integrity must be reestablished. This is achieved by preserving the server with the cache that runs for the longest (as it has the potential to contain the majority of the valid states). Other servers are restarted, which effectively means (among other things) that part of the authenticated sessions created during the disconnection time is lost.
Servers Definition
For the Static Cluster Resolution, all Servers in the DirX Access cluster must be defined before the start of the operational phase. This is feasible and actually desirable for deployments with only several servers. Downtime of some of the servers is then considered as an exceptional event, not a dynamic forming of the cluster.
Deploying DirX Access Servers in a Single Cluster Group
You can increase the availability rates and responsiveness of your system by installing multiple DirX Access servers for transparent failover and load balancing.
The following diagram illustrates a server deployment, in which four DirX Access servers provide access to three application servers, with automatic failover and load balancing.
To enable transparent failover and load balancing on your system:
-
Install multiple DirX Access servers. For increased security, you can locate these servers in an isolated subnet on your network and block off all ports not required for communication to and from these components.
-
Configure your DirX Access servers to be members of a single cluster group and DirX Access PEPs to communicate with that given group.
Deploying DirX Access Servers in Multiple Cluster Groups
As an alternative to deploying multiple DirX Access servers using load balancing, or as an additional strategy to complement your system, you can install a DirX Access server co-located with and dedicated to a single PEP. This strategy provides two advantages:
-
The applications with dedicated PDP servers will gain in performance, since no other components are requesting policy decisions from the PDP, and communications between the PEP and PDP do not need to traverse the network.
-
No additional hardware is required for the server, saving money and increasing scalability.
The following diagram illustrates a deployment in which two application servers are each protected by a dedicated DirX Access server co-located on the same host.
When a dedicated DirX Access server initializes, it only loads policy objects related to its configured application server into the system cache. This provides additional performance gains, since the PDP has fewer policies to consider when evaluating authorization requests.
To enable the distributed DirX Access server deployment:
-
Install multiple DirX Access servers. For increased security, you can locate these servers in an isolated subnet of your networks and block off all ports not required for communication to and from these components.
-
Configure your DirX Access servers to be members of different cluster groups and DirX Access PEPs to communicate with its corresponding groups.