<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<header class="entry-header">
<h1 class="entry-title">MidPoint in Higher Education:
Provisioning, Deprovisioning and Synchronization, Part II</h1>
</header>
<p>This is the second part of the blog about provisioning. In <a
href="https://evolveum.com/midpoint-in-higher-education-provisioning-deprovisioning-and-synchronization-part-i">the
first part</a> we were talking about just-in-time provisioning,
authorization and just in case provisioning. Let’s have a look at
some other types of provisioning and related topics.</p>
<p><strong>Provisioning performance</strong></p>
<p>The importance of provisioning speed is often overrated. Most of
the operations are done automatically in circumstances where time
is not crucial at all. For example, if you hire new employee, you
will have their record in a personal system before their first
day. Usually, the record includes a date from which the contract
will become valid. An identity management system can process the
record at the beginning of such day (right after midnight), so
there are usually few hours before new employee arrives to the
office in the morning.</p>
<p>Another problem is the delay caused by technical nature of target
systems. For example, when you provisioned a user to a cloud
service, it might take some time before the account will be
processed by the cloud (synchronized over all nodes). Until the
processing is ready, new user might have limited access or won’t
be able to use the service at all. A similar situation happens
with deprovisioning from web services. Even when you deprovision
the user immediately (for example, because their account was
compromised), it usually won’t destroy an active session the user
or the attacker already has. Rebooting whole server after each
change to delete all active sessions is usually not the option
either.</p>
<p>On the other hand, I have to admit there are situations where
instant provisioning might help. There are situations when users
are directly involved, for example, requesting a change either
through support or through self-service. But even there, the
actual experience shows us users are often happy with an answer
like: “your account will be active in 30 minutes”. The last reason
for speed is development and testing, where seconds feel likes
minutes and minutes like an eternity. To sum it up, even though
the performance is not that important, it improves user experience
and makes life of identity engineers easier while introducing new
changes in the IdM system.</p>
<p>That is the reason why midPoint is designed in a way where
provisioning speed is valuable, but it is not the most important
thing. Consistency and the ability to recover from unexpected
states are always in the first place because speed is not crucial
when you cannot rely on the result.</p>
<p><strong>Messaging</strong></p>
<p>The idea of using messaging for provisioning is recently becoming
new trend. The basic idea sounds just great. Messaging enables us
to pick up changes immediately from source systems, process them
in the identity management system and instantly provision them to
target systems. That should significantly enhance the speed of the
whole process, shouldn’t it? Yes, the speedup is there but not as
significant as you might think. MidPoint is provisioning all
changes instantly regardless of messaging being used or not.
Therefore, there is only potential for slowing down in case the
target systems are not processing messages immediately. Using
messaging for inbound direction to midPoint is more promising.
Without messaging, midPoint uses live synchronization task, which
picks up changes from a source system and processes them
immediately. The task is lightweight enough to be executed each
minute or so. Therefore, the messaging might bring on average 30
seconds speedup in processing a single change. The throughput will
remain the same. Therefore, if you have larger bulk of changes,
the speedup will be still only about 30 seconds on the whole bulk.</p>
<p>Unfortunately, the speedup comes with a cost. Identity management
is not about speed, even though it helps. It is about consistency.
Identity management’s main role is to guarantee that all accounts
exist where they are supposed to, and access rights and attributes
are updated accordingly. Imagine what will happen if one message
cannot be processed, for example, because it won’t pass data
validation, which is happening in real environments more often
than we would like to. There is almost no chance to recover
automatically. Processing the problematic message can’t be skipped
because the other messages might depend on it being processed.
Theoretically, you can mark the relevant object (e.g. user)
synchronization as failing and process only messages containing
other objects changes as usual. But still, there is no way to
recover automatically, using only the message stream.</p>
<p><strong>Reconciliation</strong></p>
<p>What you need to recover is a reconciliation process. That means
the ability to compare data between IdM and target/source system,
and resolve differences. Obviously, this issue cannot be solved by
messaging because you need to compare the whole state on both
target and source. Even dumping the entire state in messages won’t
work because it can’t delete redundant accounts on the receiving
side. It’s not possible to get a message about the account which
is not existing anymore in the source system state. Reconciliation
will also solve the situation when there was manual change in a
target system or if the system was restored from backup. Such
situation is typically difficult to solve using only messaging.</p>
<p>We have established now that reconciliation is necessary for
production-grade systems. Let’s move forward and think about the
combination of reconciliation with messaging in practice.
Reconciliation is a basic feature of midPoint, which is supported
by most connectors. Since the reconciliation will be needed
anyway, and theoretically, you don’t need anything else, it is
logical to always start by implementing it first. The next step is
not that straightforward. If you need to provision to a target
system, you don’t need anything else. MidPoint can automatically
provision the changes in real-time using the connector
capabilities. Messaging doesn’t bring any added value. For
synchronization from source systems, you have the option to enable
live synchronization if the source system supports it. If the
source system doesn’t support it or you need to eliminate the
average delay of 30 seconds of the live synchronization, messaging
will be beneficial for such use-case.</p>
<p><strong>Conclusion</strong></p>
<p>Provisioning is a complex area, and there is not a single
approach that will fit all situations. In reality, other
limitations and conditions might force us to use sub-optimal
solutions, which is completely fine when we understand its strong
and weak sides. The future will most likely bring combining
several approaches at the same time, leveraging the strengths and
eliminating the weak points. Evolveum is already experimenting
with similar ideas. You can look forward to the future blogs where
we will share our progress.</p>
<p>(Reposted from <a moz-do-not-send="true"
href="https://evolveum.com/midpoint-in-higher-education-provisioning-deprovisioning-and-synchronization-part-ii/">Evolveum
blog</a>)</p>
<pre>--
Slavek Licehammer
</pre>
</body>
</html>