MidPoint follows several design principles. One from the main is flexibility. MidPoint will never push you to change your infrastructure or even your world perception. Quite the contrary, it will give you enough flexibility to model the surrounding world precisely as you seem fit. This principle is great and not-that-great at the same time. Obviously, you never want to get to a dead-end where you are limited by the tool you are using, but having that vast configuration and customization options might bring an unexpected degree of complexity.
Usually, this is not that big of an issue as the first perception might suggest. There are plenty of guides, documentation and examples one can use to figure out how to configure midPoint for a particular use-case. On the other hand, not all use-cases are the same. Some are pretty straightforward; others are pushing midPoint to its limits. Higher education deployments often tend to be on the complex side of the spectrum. There are several reasons for that. One of them has its roots in so-called “Academic freedom”, which often influences even internal operations of a university which might also have an impact on identity management. For instance, the processes, in general, might be less rigorous as one could expect based on experiences from companies. Each faculty can have its own rules for assigning roles or generating an email address and other similar exceptions.
Another example of the higher education environment complexity is the complex life-cycle of user identity, which is completely natural there. Apparently, there are students and employees, but one can also be a student and an employee at the same time. Employees are often divided into academic and support staff; students become alumni; then you have external collaborations, applicants for studies, members of life-time education, contractors, professors emeritus and so on. One user can have multiple such affiliations at the same time and can get a new one or lose an existing one in any moment.
Let’s demonstrate it on an example: we have an applicant for studies, who is admitted and becomes a student. During his studies, he manages getting a part-time job as an assistant in a laboratory. Therefore he becomes a student and an employee. After finalizing the studies, he decides to apply for a master’s degree programme and gets admitted. Simply as that in real world, in the IdM it means he will in short time go through following states: student+employee -> alumni+employee -> alumni+applicant+employee -> alumni+student+employee.
Still easy? That only means we haven’t dove deep enough yet. So far, we were covering only users and their affiliations. Let’s put an organizational structure in the mix. One user can be a student of a faculty, but an employee of other faculty at the same time. Also, he can have multiple studies affiliated with different faculties or even multiple employee relation to different organizational units, which is usually a consequence of involvement in various research projects.
Even when we manage to untangle this complexity, the job is still not done. The academic environment is about collaboration which couldn’t be limited with something as binding as organization structure. Therefore we have to support dynamic groups combining all types of users, leveraging existing organization units in combination with manually managed members and various exceptions.
Hopefully, this list of complexities was enough to illustrate the problem scope that higher education is dealing with. Similar complexity and non-straightforward approaches will be most likely present for other IdM tasks as well.
What does this all mean for midPoint and Evolveum? Well, we are up for the challenge! We are dedicating part of our efforts to explore use-cases in higher education to come up with ideas on how to solve them using midPoint or to bring new ideas for future features and improvements for midPoint. Hopefully, this task will help not only higher education but also others who have similar issues to deal with.
The “MidPoint in Higher Education” blog is actually designed as a series of blog posts, which will cover some higher education use-cases and provide example solutions for them. It won’t be a step-by-step guide nor documentation replacement, but rather sharing ideas and pointing out exciting configuration options. You can look forward to model situations, ideas on how to represent them in midPoint, configuration samples, and so on. Next blog post will be focused on different user relations with organizational units.
We are open to suggestions for this blog series’ next topics, as long as they fit the overall scope. Feel free to share your ideas in the comments, at midPoint mailing list or any other channels.