Security Guide

This page describes the principles and procedures of midPoint development that relate to information security.

MidPoint development team takes security of midPoint very seriously. Security was an integral part of midPoint design since the day one. And security issues are always a priority, regardless of who and when reported them.

MidPoint support process is prioritizing issues of the subscribers, which means that a non-subscribers usually has to wait a long time for their issue to get fixed. But that does not apply to security issues. Security issues are always addressed with highest priority, regardless whether they are reported by subscriber on non-subscriber. The reason is that a security issues has potential to affect everybody, even midPoint subscribers. Therefore it is addressed immediately.

When MidPoint instance is started for the first time is creates a default configuration. The goal of the default configuration is provide starting point for midPoint customization. The default configuration is not meant to be complete or completely secure. For example, the default End User role has quite a broad privileges, there is just one global all-powerful administrator and so on. Please do not use the default configuration in a production environment unless the configuration is properly reviewed and customized to your needs.

One of the usual responsibilities of an IDM system is to manage credentials, including passwords. MidPoint is an IDM system and, naturally, there is a password management component in midPoint. But being an IDM system the password management in midPoint is much more complex that a password management of any ordinary application. MidPoint does not manage a password just for itself, it manages passwords for other applications. And then there is a problem. It is easy to to set up new accounts in a "big bang" provisioning case. This means that a new user is created in midPoint, new password is generated and that password is used when creating a new accounts at that very moment. But there is a problem if a new account has to be created later. For example, if an used gets assigned new role which needs new account to be created. In that case we do not have user’s cleartext password any more. Therefore we cannot use it while creating a new account.

MidPoint supports two methods to deal with this problem. One is more convenient, but there are security issues. The other is less convenient, but more secure. MidPoint supports both methods, as both may be needed in practice. And then, of course, there is an option for midPoint not to manage passwords at all.

This pages is giving only a high-level overview of the mechanisms. Please see Password Storage Configuration page for the details.

MidPoint is a very flexible system. Being an identity management system, all the flexibility is needed to allow practical and efficient deployments. However, with great power comes great responsibility.

One of the most powerful parts of midPoint are mappings and expressions. Expressions allow to customize midPoint behavior and they are essential for the success of midPoint deployments. However, the expressions are very powerful and they may even be too powerful for some use cases. The expressions can use general-purpose scripting languages such as Groovy or JavaScript. Therefore such expressions have almost unlimited capabilities. Which means that the expressions can damage the system or compromise security of the system. Use the expressions with utmost care.

Currently, there are very little restraints for expression execution. The expression functions provided by midPoint usually check for proper authorizations. But as the expressions can use general-purpose languages, there is no obligation for the expressions to use those libraries. The expression can easily circumvent those weak protections. Therefore do not let any unauthorized user to set up any kind of expression in midPoint. Allowing the right to edit any expression may lead to compromise of system security.

Some expression security can be achieved by using expression profiles. However, the usefulness of this feature is currently limited. See Expression Profile Configuration page for details. Please consider using platform subscription to fund full implementation of expression profiles.

Stand-alone deployment of midPoint is supposed to expose only HTTP port 8080 by default. Other ports (e.g. H2 database port) may be exposed as well, depending on midPoint configuration and customization.

MidPoint is not supposed to be directly exposed to unprotected network. It is assumed that additional network protection will be applied, such as HTTP/HTTPS reverse proxy. Many midPoint deployments will take benefit of clustering mechanisms and those will be multi-node deployments. Therefore a form of HTTP/HTTPS reverse proxy is expected anyway, e.g. in a form of a network load balancer.

Due to operating system security reasons and limitations of the Java platform, midPoint listens at port 8080 by default. This is usually not the desired solution, as ports 80 and 443 are usually expected. Therefore this is yet another reason for using a network security component in front of midPoint.

See also Ports 80 and 443.

MidPoint deployment that are explicitly deployed into existing web container environment (Apache Tomcat) should adhere to the recommended security practices of the web container. As such web container is not under the control of midPoint, midPoint is not responsible for any security issues of such web container.

MidPoint is exposing remote services, such as RESTful API. Those services provide access to a significant part of midPoint functionality. The services allow "raw" access to midPoint data, which means access that is not protected by the mechanisms of user interface. Significant harm can be done by using those services, as there are almost no safeguards with respect to robustness. E.g. the services will not ask for confirmation dialog, they will allow to delete objects that are in use and so on. Significant care should be employed when using those services.

MidPoint remote services are using the same authentication credentials as ordinary midPoint users. However, special authorization is required to access those services. Both service authorization and object authorization are required to access the service and execute operations. Therefore even a user that has very broad privileges in midPoint user interface cannot use those privileges in the context of remote services unless special service authorization is in place.

Administrators are advised to give access to the services very carefully. Those services are designed with the purpose of being comprehensive, secure and general services that are exposing (almost) all functionality of midPoint. However, the implementation has not reached that stage yet. Some parts of the service will be further developed in the future. Current purpose of midPoint remote services is to allow access to few trusted applications that implement the barriers the midPoint services do not provide yet. The services are not meant to be used by end users directly.

There are many ways how the use of midPoint services may impact availability of midPoint functions, creating Denial of Service (DoS) situation. The user of the services may create messages that are too long, flood midPoint servers with many messages, depleting network resources, craft messages that overload the server hosting midPoint application or use similar mechanism. Therefore it is recommended to prohibit access to midPoint services on network level, make them available only to trusted entities.

MidPoint is an application, running on existing computing platform. There is operating system and Java platform as two major components. There are also engines that are embedded in midPoint, most notably Tomcat web server and Groovy, JavaScript and Python interpreters. Although we try to make sure that midPoint is interacting with the platform and its dependencies in a secure way, it is recommended to use the usual practice to secure the host system where midPoint is running, limit the exposure of midPoint network services and use similar security practices to limit the exposure of midPoint instance. Also, we try to make the scripting interpreters safe. However, the scripting languages create very complex environment, and as most software packages, some scripting operations may be vulnerable to some forms of attacks. Therefore it is recommended to follow security advisories of the scripting platform that you are using to create midPoint customizations (e.g. Groovy) and adapt your code to avoid vulnerabilities given by the platform.

We recommend not to use experimental features in security-sensitive deployments. Experimental features were subjected only to a very limited amount of testing - including security testing. The functionality may also change at any time in quite unexpected way, there is limited documentation and so on. Therefore you should either thoroughly test the experimental functionality yourself or do not use it at all.

MidPoint team is often asked if midPoint has any security certifications. This is a very difficult questions to answer. MidPoint is an identity management product. As such, it is very flexible and it can be configured and customized ad nauseam. There are too many things that can go wrong during the configuration and customization, few of them are described in this guide. Therefore even if midPoint as a product had a security certification, it would not make any guarantees about security of a particular midPoint deployment. To make the situation even worse, product security certifications are very expensive. It is a long and laborious process. The cost of such a certification would need to be reflected into the cost of midPoint subscription and all users would be impacted. And as product certifications are only valid for a particular version of a product, we would need to repeat the entire process every 6 months. This approach is just too costly and it provides very little benefit for midPoint user community. Therefore we have decided not to go this way.

However, midPoint is an open source product. All the source code and all the information that is needed for a certification is public. Therefore if any particular midPoint user insist on security certification, such user has all the necessary information to follow through this process.

While product security certifications is out, there are other methods that can be used for security testing. Penetration testing is a popular choice here. But similarly to the security certification, penetration testing is usually done against a deployed application, not a general-purpose product. Penetration testing almost always uncovers problems with configuration, not problems with the products. Albeit all that, there is still some chance that penetration testing may uncover a flaw in generic midPoint implementation. Therefore we would be willing to participate in a penetration testing exercise with midPoint. However, so far there was no one that would be willing to fund such activity.

Fortunately, there are other methods. In early 2019 midPoint was a part of European Union Free and Open Source Software Auditing (EU-FOSSA2) project. A bug bounty was announced for vulnerabilities in midPoint product. The bug bounty program was very successful, resulting in discovery and mitigation of several security issues.