System Requirements

The midPoint deployment consists of the following units:

Each of these deployment units have slightly different characteristics and requirements, therefore each is described in a separate section below.

MidPoint server is the main part of any midPoint installation. MidPoint server takes most of the load from user interaction and data processing. Therefore it is most sensitive to the CPU load and RAM size. The table below summarizes the recommended resources for typical scenarios:

^* Deployments with more than 100,000 users are supported in midPoint. However, due to variability in large-scale environments, it is recommended to consult the specific hardware requirements with Evolveum Support.

Database system is used to store the vast majority of midPoint data.

The load on the database system is most sensitive to the size and character of the data, the usage patterns, and also the type and configuration of the used database system. Use the values below as general guidelines and adjust them to fit your use case. For a more precise estimate, consult the Evolveum database engineers.

^* Deployments with more than 100,000 users are supported in midPoint. However, due to variability in large-scale environments, it is recommended to consult the specific hardware requirements with Evolveum database engineers.

The recommended values assume that midPoint is used to store operational data, and only a reasonably small amount of historical data (e.g. audit records). If you are planning to use midPoint to store historical data, a proper data retention and capacity planning must take place before evaluating the database sizing.

Connector Servers are small software components that act as a proxy for connectors that cannot run inside midPoint. Deployment of these components is quite rare.

Resource requirements of connector servers are extremely small. It is usually too small to measure: a tiny portion of CPU and RAM, and a disk space measured in megabytes. We strongly recommend deploying these components on shared servers.

There are several approaches to implement high availability (HA) for midPoint deployments. Each strategy has different characteristics and costs:

Refer to the midPoint Releases documentation for software requirements.

When you start an IAM project, not only midPoint servers but also the database and load balancer (if required) must be prepared. You need to have access to the infrastructure in which these servers are running, and also to the source and target systems. In most cases, the infrastructure is prepared by the administrators on the customer site. The next schema represents a basic scenario:

You can see one midPoint installation with sample connections. In most cases, the biggest square with the midPoint logo is represented by a Linux virtual machine with preinstalled Java SE development Kit (for example OpenJDK), Apache Tomcat from a Linux repository prepared to run as a service, and tools like telnet, wget, mlocate. A Windows server is rarely used. You can install the latest midPoint release, however in most cases, the installation is provided by an Identity engineer (supplier).

For the database repository, an existing DB server is usually used. You have access to it over the SQL protocol (for example MS SQL on the default TCP port 1433, 1521 for Oracle, etc.) from the midPoint server. Do not forget to configure your firewalls. Also, a new DB schema is created for midPoint with a new technical user and DB owner permissions. Sometimes we have a separate DB server or can we use a DB server in the same virtual machine where midPoint is installed (only in single-node mode).

If e-mail notifications are needed, access to the SMTP server and also a new account with send privileges is required. You may also need access to an SMS gateway, and have the account privileges to send SMS.

Many deployments are provided remotely. The best practice is to prepare a secure VPN access for each team member separately with direct access to the midPoint server over SSH. This should have enabled tunneling and HTTPS access (8443 is the default internal Tomcat port, or 443 with transformation to the Tomcat port). In most cases, midPoint Web UI (self service) is also accessible via HTTPS for all employees in customer intranet.

Other source systems are HR, for example, represented as an Excel table (HR 1 in the schema). An HR manager saves the current content after each change (or once a day/week) into a CSV file to the location where midPoint can read, proceed & rename the CSV (File share). If there is a sophisticated HR system, we can access the employee and organizational structure data through prepared read-only DB views. This is done directly through SQL (HR 2 in the schema) prepared by the HR supplier - an SQL account is required. Or we can use the existing SOAP or REST APIs to read these data - API account/key is required.

The most frequently used target system is LDAP (for example, Open LDAP with its standard port 636 or 389), or Active Directory that is used when we also need Remote Desktop Connection (RDP). This is typically used directly from the workstation, however, tunneling through the midPoint server is also possible. Also, a technical account with full permissions to the respective DN or domain is required.

Connection to other target systems can be established over REST API (Application 1 - HTTPS), SOAP, SCIM (Application 2, 3, …​ - HTTPS), SQL, or some other proprietary service (for example SAP and JCo). With those, you will need to enable API, open your firewall on servers where the system is running, and create an account with respective access to manage identities. Sometimes, when cloud services are used (for example Office 365), access to internet is granted over a proxy server.

In some cases, midPoint may also need to have local access to the system (Application N). In this case, a connector server component is installed on the server where the system is already installed, for example to run some scripts to prepare the home directory.

If the situation requires two or more midPoint nodes, the schema looks like this:

Identity engineers need VPN access to all nodes (node 1, node2: SSH & Tunnel, and also HTTP/S access to the local Tomcat that can be tunneled). Node jobs are synchronized over JMX.

Each midPoint node needs to have access to the SMTP server (if notifications are required), shared HA DB Repository, and all source and target systems to have full HA support. When a node is down, other nodes need to be able to replace all of its jobs.

End users and identity engineers use midPoint Web UI over a load balancer (HTTPS).

You can check that connections to all source or target systems are working using the following tools: ping, telnet, and wget. You can use them from the midPoint server and also from the workstation (once tunnels have been configured).

In IAM projects, at least two environments are typically used: test & production. In many cases, there is also a local midPoint installation on the identity engineer’s workstation, and another development environment in the customer’s infrastructure.

The best practice is to use a configuration that is as similar as possible in all of these environments. However, it should also be completely isolated without access, for example, from the test midPoint environment to production Application 1. VPN can be shared.

For identity development, it is recommended for the test and production environments to have the same operating system (and version), application version, and data for all source and target systems. Any differences may lead to situations where something is working and is well tested in one environment, but does not work in another environment.

If data are sensitive, and cannot be used in the development phase, you can obfuscate them and only use a part of them as a sample. However, the schema and all attributes that you are using need to be used the same way as in the production environment to minimize differences.

If you are also deploying the solution to production, you need to have access to the production environment and the data there. It is not necessary to obfuscate data for the test or development environments, because the same identity engineer is responsible for the development, testing and deployment.