[midPoint] Use in higher education?

[Radovan Semancik]

Hello

On 02/18/2016 11:15 PM, Richard Frovarp wrote:
> My question is how much of my need can be met by midPoint? I 
> understand that it is a provisioning engine, which is what I'm after. 
> Our self service needs are unique enough that this functionality would 
> remain a separate system.

Pavol already answered most of that.

I would just add that midPoint has a comprehensive interface that can be 
used to control approx. 95% of all midPoint functionality. That 
interface is available as local Java, SOAP-based web service and REST. 
So making a custom GUI on top of midPoint is possible - even if that 
custom GUI is very rich. In fact, this is the same interface that our 
stock GUI is using. The details are here: 
https://wiki.evolveum.com/display/midPoint/Interfaces

> How painful is it to have a large number of attributes on a user? I 
> see in the demo how a couple were added. To start tracking everything, 
> I'm going to need a lot more. As noted in the comparison, academia 
> doesn't have clean organizational units.

As Pavol already mentioned, the only slight pain point now is the GUI. 
But if you are going to have your own GUI then it is perhaps not a 
problem for you. Even for stock midPoint GUI there are improvements 
planned for next midPoint release (version 3.4 planned to be released 
before the summer).

> Is there any sensible way to store something like course registrations 
> in the system? I'm guessing that I'll still need to manage that 
> separately for the systems that need that information and/or to make 
> decisions off of that information.

In addition to Pavol's suggestion there might be another way: you can 
model courses as midPoint organizations ("orgs" as we call it).

MidPoint organizational structure is very flexible: it may have multiple 
roots, it does not need to be a strict tree and in fact it can handle 
anything that can be modeled as series of oriented acyclic graphs. Then 
you can use midPoint assignments to represent student-course relation 
(attending the course), teacher-course relations, etc. The "orgs" also 
behave as roles. So this will give you very flexible access control 
model, e.g. for delegated administration of courses. I would recommend 
this approach. There are some drawbacks, though. Firstly, the current 
midPoint GUI is not well designed to properly handle big number of 
assignments. There are improvements coming in 3.4, but you will need a 
custom component to display this information conveniently. We are 
currently going in this way. The master development branch has an 
ability to add custom forms (as Java + Apache Wicket components) and 
that will be part of the 3.4 release. Secondly, I'm not entirely 
confident about scalability here. Theoretically midPoint should be able 
to handle that. We have just never tested this scenario and practice 
often has some surprises in store. So it might be good idea to prototype 
it first.

> It's not immediately obvious to me, how hard is it to write a 
> connector that operates asynchronously? The RabbitMQ model works quite 
> well for us, and it would be quickest and easiest to to move those 
> over as is until time permits new options to be developed. For some of 
> them doing PowerShell, there might not be good other options anyway.

That is currently one of the harder issues. MidPoint now operates 
synchronously for vast majority of operations. To be completely honest, 
this is partially a design feature and partially current limitation. It 
is a design feature because synchronous systems are much more easy to 
diagnose and debug. E.g. in midPoint we can complete state of every 
operation (called "Model Context") that is maintained through the entire 
operation (which can take weeks if there is an approval process) and 
that also contains most of the operation side-effects. So we have quite 
a good idea of cause-and-effect relationship in midPoint. And this is 
especially critical if you have configured complex policies in midPoint 
- and many deployments have really complex policies. But the synchronous 
nature is also a partial limitation. This is mostly given by the fact 
that the underlaying connection layer is synchronous. This is the ConnId 
framework which is based on Sun Identity Connector Framework. We have 
started there and this has somehow given the synchronous nature of 
midPoint. But speaking from the experience working with both synchronous 
and asynchronous systems: I will choose a synchronous systems whenever 
possible, especially if it is a complex one. Diagnostics in the async 
system is just a nightmare and there is not much that can be done about 
it. On the other hand, midPoint has good diagnostic potential and the 
crucial features are implemented in midPoint core since the very 
beginning. And even though all of that is not yet visible in the GUI, we 
are now working hard to improve this particular point.

Having said that I also have to say that there are some 
semi-asynchronous parts in midPoint. E.g. we have live synchronization. 
This is now implemented by invoking ConnId function that actively polls 
for changes. But it in fact not entirely unlike polling the message 
queue for new messages. There is also notifyChange() operation in our 
interface that can be used for asynchronous processing.

There is more async features planned for future midPoint development. 
But as of now the people that fund most of the midPoint development have 
endorsed other features as more important than this and the sync 
features do not yet have a specific date on them. But that might change. 
MidPoint contributors and subscribers have the power to influence 
roadmap ....

> How does it handle username changes? The connectors would need to know 
> what the old username was, and what the new one will be so they can 
> find and update the username in the remote system.

This is one of the things that we handle quite well. Most source and 
target systems have other identifiers except for username. And those are 
usually persistent and immutable. E.g. modern LDAP servers have 
entryUUID, Active Directory has objectGUID, databases often have 
persistent numeric primary keys and so on. MidPoint will primarily use 
this identifier to link users and accounts. Therefore we can detect that 
username changes in a similar fashion as we detect change of any other 
ordinary attribute.

> We also need to keep track of training / terms of service usage that 
> needs to be renewed. This then drives access to other systems. I'm 
> guessing that we could implement that via assignments with expiration 
> dates that are then used as dependencies for other services?

Yes. That is a good choice for expiring the assignment. That is actually 
very easy. You can also use customized workflow to support requests and 
"onboarding". However, currently we do not have capability to easily 
handle renewals. E.g. it is not easy to trigger an event when 
assignments expire. But we have plans to do something about that in 3.5, 
as it is needed for the governance features that we are currently 
working on. Again, as midPoint subscriber or contributor you would have 
the ability to influence the roadmap and get the features that you need.

-- 
Radovan Semancik
Software Architect
evolveum.com