Understanding the Xton Access Manager Architecture
Xton Access Manager server is installed on a single or multiple physical or virtual computers. We call each computer a node. Single node setup is very easy and quick. However, administrators might decide to use multiple nodes for the server installation to increase performance, to improve availability (in case when one of the nodes malfunctions) or to improve security (to separate master password and encrypted data).
Xton Access Manager server is constructed from several types of blocks. Administrators can install all these these blocks on one single node (remember, a node is just a physical computer or a virtual machine). This is what we recommend for trial or a light system use to simplify the installation process. We call such virtual or physical computer – a node. Note that each node might contain multiple blocks or different type.
Alternatively, an administrator may decide to install some of the blocks on one node and some other blocks on the other nodes to increase overall system performance. Moreover, an administrator can install more blocks of the same type on different nodes to increase system performance, to improve system availability or to improve internal system security.
So what are these blocks that together construct an Xton Access Manager server?
- Application GUI or WEB Front End is the block that interacts with users using WEB GUI or with scripts using API. The server may contain multiple Application GUI blocks installed on different nodes to make the system serve users faster. Each Application GUI block might serve many users or script requests. However, more users access the system more Application GUI blocks might be installed. When the server users multiple Application GUI nodes, the administrators should install a Load Balancer block (on one of the nodes or on a separate node) to balance the use of WEB Front Ends.
- Job Engine is the block that executes background processes like password reset or discovery. The server might contain multiple Job Engine blocks installed on different nodes. Each Job Engine block can handle many password resets or discovery queries. However, adding more Job Engine nodes increases the speed of these tasks because more of them will be executed at the same time. The system includes flexible configuration of Job Engines on each node. It allows to disable some processes on some nodes and adding more threads (parallel tasks) for certain nodes.
- Session Manager is the Jump Server gateway. This block displays remote computer screens in the users browsers. The server might contain multiple Session Managers. Each session manager can handle multiple simultaneous sessions. However, when the server has to support too many sessions, an administrator can add more Session Manager nodes. Moreover, Session Manager node might be installed at a strategic location that can access certain computers on the network. The server includes flexible configuration that allows selection of session manager depending of the location of the destination computer
- Directory Service is a block that contains local system users and also a master password. The server might contain only one Directory Service. However, administrator may decide to host this block on a separate node to separate physical master password location from the encrypted data in the database.
- RDBMS is a block that stores all internal system data (with the exception of local users and master password stored in the Directory Service). The server may contain only one RDBMS node. The server is shipped with the internal database that should be installed on one of the nodes with either Application GUI or Job Engine. However, administrator might decide to use one of several external supported RDBMS. We do not count RDBMS node in our licensing model.
- Federated Sign-In is a block that performs user authentication. The server might include only one Federated Sign-In block.
To illustrate the use of the nodes we will describe several typical deployment architecture scenarios
- Trial. All blocks could be installed on a single node using default installation options.
- Light Use. All system components could be installed on a single node like during the Trial but exposed to the outside world using Load Balancer with secured SSL HTTPS connection through the standard https port 443. Clients will need to install their own certificate for the known host name. Federated Sign-In service might or might not be installed in this case depending whether basic authentication through the secure channel could be enough for the system operations. This is our primary recommendation for the initial or light use in a typical SMB organization
- Light Use with Improved Security. Directory Service could be installed on a separate node to move master password out of the computer with the main database and the software installed
- Enterprise Database. While internal RDBMS shipped with the system is a reliable database it is possible to connect all components (Application GUI and Job Engines) to external database scheme supplied by the user. The system will create and populate the data tables automatically during the first run or data import. The database could be a Derby database installed as a part of different computer node or it could be any other certified RDBMS supplied by the user.
- High Availability scenario is achieved when Application GUI, Job Engine and Session Manager components deployed to two different nodes connected to the single RDBMS accessed through the single Load Balancer and using a single Directory Service possibly offloaded to a third node. This three-nodes setup is a minimal configuration for high availability moderate performance deployment including improved security option.
- Many Users scenario addresses the situation of many users accessing the system Application GUI simultaneously mostly for the data managed by the system without accessing many remote computers. In this case Application GUI could be deployed to several nodes accessed through the load balancer connected to the same RDBMS and Directory Service to improve system reaction time.
- Many Sessions scenario addresses the case of many simultaneous sessions to remote computers established by system users at the same time. The sessions might include multiple users attached to the same computer (session sharing) or users accessing different computers. In this situation Session Manager could be installed on multiple different nodes to reduce the load to each individual Session Manager. Application GUI will load balance Session Manager selected to access specific computer group based on the number of sessions currently opened on an Session Manager. In addition to that some Session Manager components could be installed at the strategic network locations to provide (better) access to certain network resources. IT creates Session Manager proximity groups that define groups of Session Manager services that access certain computers selected by IP addresses or by name pattern
- Many Jobs scenario covers the case when there are many parallel password reset, script execution, notifications, or discovery jobs running in the background. In this case the Job Engine component could be installed on the multiple computers connected through the single RDBMS to reduce the load on any particular node. The Job Engine component could be configured to increase, decrease the thread load for every particular process or to disable certain processes on some nodes completely. For example, some computers might only handle password reset jobs while other computer might only handle notifications. In addition to that some Job Engine components could be installed at the strategic network locations to provide (better) access to certain network resources.
- Combination scenario allows use of any previous deployment configuration. The complete system application farm might contain multiple nodes distributed across multiple network locations accessed through a single HTTPS entry point.