For ZČU it meant to start looking for a new, modern solution of at least the same quality. The main requirements were license independence on the number of identities, roles, and connected systems, open source, possibility to develop own connectors, independence on the operating system, support of common databases for object repository, support of authentication against Active Directory and LDAP, product support, continuous development from the manufacturer and adding new features, modern design and use of modern technologies.

The winner of the tender was Evolveum’s product – midPoint Identity Manager offered by the implementer AMI Praha a.s. The product offered all required functionalities or could be implemented in a documented and officially supported way. MidPoint is offered as open source, so it can be downloaded from the company’s website free of charge and even without any registration. Judging by the high activity on the product forums, midPoint is widely used, and new and new functionalities are added by the development team. According to feedback from its users, midPoint is a very popular identity management tool and is being implemented in universities as well as commercial and government companies.

ZČU operated Sun Identity Manager as a tool for managing employees, students, and external students. The source of data on employees was the Magion application, the source of data on students was the STAG application and the source of data on freelancers was the IdM itself. The collected data was then distributed via IdM to the target applications. The Grouper application was used for role management, which was outdated and functionally inadequate.

From a technical point of view, the following steps had to be performed:

• Replace the obsolete Grouper application – its functionality was taken over by IdM
• Prepare the IdM user interface for use by users in different roles
• Connect to IdM the source systems of staff, students, organizational structure, course list, study list, etc.
• Allow employees to create guest accounts in IdM
• Set up Kerberos authentication on IdM
• Connect target systems for data consumption

IdM midPoint deployment

The hardware and software requirements of midPoint are not exceptional and do not differ from those of similar products. The recommended operating system is any common Linux distribution. In addition, Apache Tomcat version 8 and higher, Java Development Kit version 8 and higher, and MySQL, MSSQL, Oracle, or PostgreSQL databases for storing identity data are required.

The choice for the ZČU was Debian operating system, Apache Tomcat version 8, Java Development Kit version 8, and Oracle. The server was created in a virtual environment and was allocated 32 GB of RAM and 150 GB of disk space.

The installation of IdM midPoint itself was also not very complicated and consisted of a few steps: running a script to create the DB tables of the future IdM midPoint repository and then downloading the midPoint WAR file from Evolveum’s website and copying it to the web app’s directory in the Apache Tomcat installation. The Tomcat auto-install service then installed and made the midPoint web interface available.

This completed the basic installation and allowed the applications to be connected and the required functionality to be implemented.

Requirements

Several dozens of requirements and suggestions for incorporating functionalities into the new IdM midPoint were collected through discussions with IT department representatives. This list was mainly based on experience with the operation of the previous Sun IdM solution. In addition, there were requests from regular users working with IdM that could no longer be incorporated into the previous IdM or would require high costs to incorporate. The list was also supplemented with new requirements arising from gradual changes in the processes at the ZČU.

One of the main requirements was to transfer the existing functionality from the original IdM to the new solution so that the functionality itself would be preserved, but the features of the new IdM solution would be used to the highest possible extent. It was therefore necessary to design and then set up the IdM environment so that users working in IdM could perform only those tasks that belonged to them in terms of their role.

Another important requirement was to transfer all functionality of the Grouper application to the IdM environment. This was the functionality to automatically assign roles to employees according to their placement in the organizational structure and to automatically assign roles to students according to their studies.

Connecting applications to IdM

Applications are connected to IdM using connectors that are already prepared for common applications (LDAP, database tables), or it is necessary to program such connectors in a documented and supported procedure (typically various web services).

In the following paragraphs, we will list the individual applications connected to IdM midPoint and briefly describe how to connect them.

We connected the Magion application using a connector programmed to the customized database views. The connector was later rewritten directly into Java for performance reasons. Database views provide IdM midPoint with data about employees, the positions of employees (departments, faculties, chairs), and the organizational structure of the ZČU.

We connected the STAG application similarly to Magion using a programmed connector tailored to the web services that STAG contains. The web services provide IdM midPoint with data about students, their studies, and courses studied.

Another connected application is STAG_UCITEL. This is another set of STAG web services that consumes information from IdM midPoint about the teachers using this application. IdM midPoint uses these web services to control teacher access to the STAG application. As in the previous cases, the application was connected using a programmed connector serving these web services.

The JIS application was again connected to IdM through the web services provided by JIS. IdM midPoint provides information about staff, students, and external students and their positions to the JIS application. Back into IdM midPoint, we draw data on issued access cards.

Unlinking existing applications

Due to changes in the architecture of the application and IdM midPoint links, we were able to design simplification and optimization of some of the IdM links to the point that we were able to remove some of the links. These are mainly CRO and Grouper applications.

The functionalities of the CRO application have been taken over by IdM midPoint. These included generating CROIDs, creating, updating, and deactivating people, matching people when multiple positions are concurrent, archiving inactive people, and outputting data to an export table.

Grouper functionality was also taken over by IdM midPoint. IdM now provides automatic assignment of users to jobs according to their position, automatic assignment of users to org. units. Secretaries and their secretaries can manually assign users to jobs and org. units.

IdM interface for users

MidPoint includes a web interface for both end users and administrators. IdM midPoint offers users many useful features, including the ability to request roles and subsequent approval, change and synchronize passwords, or notification and reporting. As part of the IdM midPoint implementation, we addressed two basic functionality requirements – replacing the Grouper functionality and the ability to create external accounts.

The first requirement was that employees in the position of secretary or secretary’s secretary should be able to assign IdM midPoint users to a selected organizational structure tree and also to a specified role type. This was a replacement for the Grouper application. Thanks to the very extensive authorization setting options, this requirement was completely solved in midPoint.

The second requirement was that all active employees should be able to create any number of external accounts in the IdM midPoint environment. When the account was created, the employee automatically became a guarantor and furthermore, the validity of the external account was automatically set to a maximum of 2 years (unless the employee specifies less). Again, thanks to the authorization options, this requirement could be met without any problems.

Language versions

The standard part of the current version of midPoint is the Czech language package. The language settings are based on the current operating system environment of the specific user.

Conclusion

The implementation of the identity management tool in ZČU met the expectations of the management and can be considered successful. The IT management of the ZČU in cooperation with AMI Praha is preparing further requirements for the development of the implementation of this tool and is planning to connect other applications. We can highlight especially the simplicity of connecting midPoint to individual applications and the Czech user environment.

ZČU also appreciates the smooth cooperation of AMI Praha directly with the midPoint developers and their great willingness to solve problems. MidPoint, as an alternative to commercial solutions, can therefore be highly recommended.