This demo is updated from time to time. If you encounter unexpected behavior, please let us know e.g. on #incommon-midpoint Internet2 Slack channel.
This is a demonstration of using midPoint in more realistic deployment, having various source and target systems along with other identity management components like LDAP, Grouper, and Shibboleth IdP.
Starting the containers
$ cd demo/grouper $ docker compose up
This will take a while.
Finally, you will see the notice about midPoint successful start.
midpoint_server | 2024-05-24 07:23:53,374 [] [main] INFO (com.evolveum.midpoint.web.boot.MidPointSpringApplication): Started MidPointSpringApplication in 22.246 seconds (process running for 23.944)
But it will be followed by lots of messages informing about data initialization in Grouper, synchronization to midPoint and provisioning to LDAP server. You don't have to wait until everything is finalized and you might start exploring the demo sooner, just keep in mind the synchronization and provisioning are running in background.
Containers
| Container | Content | Description |
|---|---|---|
sources | MariaDB server | This serves as an example of source systems. MariaDB here hosts |
midpoint_server | midPoint software | This is the standard container providing midPoint functionality. |
midpoint_data | PostreSQL server | This container provides the repository for midPoint. It is separate, so it can be replaced as needed: either with a container hosting any other supported database, or with a non-dockerized repository (on-premises or in cloud). |
grouper_ui | Grouper software | Here the Grouper UI executes. |
grouper_ws | Grouper software | Here the Grouper WS (Web Services) executes. |
grouper_daemon | Grouper software | Here the Grouper loader jobs execute. |
grouper_data | MariaDB server | This is the repository for Grouper. In a similar way as for midPoint, it is separate so that it can be replaced as needed. |
grouper_data_init | init | Initialize data in grouper. Create loader groups and setup midPoint provisioner. This container can be replaced by static configuration, if needed. |
directory | 389ds server | This is the central LDAP directory. It is used by Grouper as a primary source of subjects and "imported" group membership (from source systems and optionally from midPoint). It is also used by Shibboleth IdP as source of authentication information. |
mq | RabbitMQ | RabbitMQ server. It's part of the Grouper deployment and not relevant for this demo. |
idp | Shibboleth IdP | Here Shibboleth IdP executes, providing authentication service for Grouper and (in the future) also for midPoint. |
idp_vol_init | init | Preparing configuration files like metadata for Shibboleth IdP. This container can be replaced by static configuration, if needed. |
proxy | NGINX | HTTP proxy for accessing midPoint, Grouper and Shibboleth IdP. |
beacon | TAP Beacon | InCommon TAP Beacon. |
data_init | init | This container is responsible for initialization of midpoint_data container. |
prereq | init | Configuration files initialization for other containers. It generates certificates, keystores and database password. This container can be replaced by static configuration, if needed. |
Composition of these Docker containers is described in docker-compose.yml file.
Checking the midPoint state
Now you can check if midPoint is up and running by logging into it. Please use URL of https://localhost/, with user banderson, and password password.
After successful login:
Checking groups in Grouper
The loaders that were created run each minute. So after a while, when logging into Grouper (URL https://localhost/grouper, user banderson, password password) you can see them. Note that the first time you'd have to accept invalid certificate and fill-in data for Shibboleth IdP. After successful login you'd choose Miscellaneous and Loader jobs you'd see this:
And, after selecting ref:affiliation:alum group you can see its members:
MidPoint - Grouper integration
MidPoint's Grouper connector is used for the integration. Grouper is provisioning data about subjects and groups to the PostreSQL database.Then midPoint is reading them out of it and mapping them to Users and Organizational units. The synchronization is using a Reconciliation task which makes sure that all relevant data are aligned between Grouper and midPoint and a Live Synchronization Task responsible for processing individual changes as soon as they appear. Both of the tasks are available in midPoint tasks.
Conclusion
This sample environment shows a proposal how to use midPoint along with Grouper for managing identities at a university. It is not a complete solution. Due to time limitations, some of the components are more sketches than production-ready implementations. For example, scripted SQL connectors do not support filtering, paging, nor live synchronization. Data model is greatly simplified. Security and performance issues were taken into account, but not yet fully validated.
Nevertheless, we consider this to be a good basis for getting acquainted with midPoint/Grouper integration as well as for future discussion on suitable architecture of midPoint/Grouper deployment in higher education.