Overall architecture

The overall architecture of this demonstration composition is the following:

Generally, source systems provide data about majority of identities at the institution: students, faculty and other employees; potentially also about external persons. Those systems are typically student information system(s), human resource management system(s), and so on. They are primary sources of identity information.

Target systems, then, are primary consumers of identity data. These could be on-premises or cloud applications or services - like, for example, Office 365, G Suite (Google Apps), Slack, Jira, box.com, Coupa, Drupal, Liferay, GitLab, many kinds of ERP/CRM systems like SAP or Siebel; even student or HR information systems themselves; also individual servers, email platforms, other directories, and so on.

Source and target systems are shown in magenta color in the above schema.

Red components deal with managing user identities. These are (in this particular case) LDAP directory, midPoint, and Grouper.

1. LDAP directory serves as the central directory of identities. It is used by both (some of) target systems and identity management components themselves.
2. Because of its flexible interfacing features, midPoint takes care about collecting (some of) data from source systems, provisioning them into the central LDAP directory and to target systems. It also carries out complex processing of the data via mappings (i.e. transformations). Optionally, it allows designated users to augment/modify/review these data e.g. by modifying users' attributes not covered by source systems, or by assigning users specific roles, organizational membership, services or resources. If needed, it can also help with governance, risk management and compliance via features like approvals, recertification, reporting, auditing, policy rules, and so on.
3. Grouper is - in this particular demo case - the primary tool for managing access policies and affiliations. Using its inclusion/exclusion mechanism it allows designated users to modify membership of groups defined in source systems. It also allows creation of ad-hoc groups that may or may not utilize pre-existing group membership.

Other components of the solution are:

1. RabbitMQ is used to achieve near real-time synchronization from Grouper to midPoint. Grouper publishes changes to AMQP and midPoint updates itself based on those AMQP messages.
2. Shibboleth Identity Provider (IdP) is used to achieve single-sign on inside and/or outside the institution. Specifically, both Grouper and midPoint users are authenticated using it.

Integration of other Internet2-provided components, e.g. COmanage, is currently out of scope of this demo.

Docker representation

Containers

The Docker containers for demo/grouper composition look like this:

Each box in the picture is one container. Name of the container is shown in parentheses in box header, e.g. sources, midpoint_data, midpoint_server, grouper_data, and so on.

Some components of the demo are present just to demonstrate the architecture (like containers representing source systems), others are present as suggestions for real deployments: midpoint_data, midpoint_server, grouper_data, grouper_ui, grouper_daemon, mq, directory, idp.

Let us describe individual containers now. (After composition is set up, the real container names are in the form of grouper_ABC_1 e.g. grouper_sources_1 or grouper_midpoint_server_1.)

Composition of these Docker containers is described in docker-compose.yml file.

Communication

The containers publish the following TCP ports. (Port mapped to localhost denotes the mapping of container port to the host port where it can be reached from the outside.)

(Some other, less important ports that are internally exposed are not mentioned here.)

Docker volumes

The following volumes are created to persist data and other relevant files.

Configuring the composition

The following configuration properties are supported. Please refer to the main documentation page for their explanation.

You can tailor these to your needs.

The following Docker secrets are used:

The following configuration files are used:

You can modify or replace these files as needed.

In addition to these, there are environment variables, Docker secrets and configuration files used to configure other components like Grouper or Shibboleth IdP. For their setup please consult relevant products' documentation.