<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 I</h1>
</header>
<p>Provisioning is, without any doubt, the key feature of any IdM
system. Without it, the IdM won’t be able to fulfil its primary
role – aggregate all identities and other relevant objects (group,
roles, …) and then distribute them to all systems and services
where they are needed. This blog will cover several types of
provisioning and related topics, and we will see how midPoint can
help in various situations.</p>
<p><strong>Just-in-time provisioning</strong></p>
<p>Just-in-time provisioning has a prominent role in academia thanks
to academic identity federations like <a
href="https://incommon.org/federation/">InCommon</a> and <a
href="https://edugain.org/">eduGAIN</a>. Just-in-time
provisioning means a user’s account is created when needed, which
typically is when a user is signing in to the service. In
academia, this is achieved by using an Identity Provider, which is
a component combining access management and single sign-on (SSO)
capabilities. SAML2 protocol is currently used the most, but
OpenID Connect (OIDC) popularity is rising each day.</p>
<p>We won’t be covering how SAML2 and OIDC works and neither their
differences. Instead, we will focus on integrating an identity
management system with access management systems in general.
Access management requires access to data about users. It has to
verify user authentication and be able to query additional
attributes of the users (name, e-mail, entitlements, …) These
attributes can be delivered using the protocols mentioned above to
services which a user is accessing. Service can use obtained data
to create or update local user account on the service.
Just-in-time provisioning is as simple as that.</p>
<p><strong>Authorization</strong></p>
<p>A careful reader may notice that we had omitted authorization so
far. In the simple case described, it is up to the service to make
the authorization decision based on the obtained attributes. This
principle is used typically in a federated environment, where
there are usually too many services to handle individually. Also,
the distributed nature of the environment complicates other
approaches. We can configure what attributes will be released,
which is far more complex topic than it initially seems. Due to
the privacy protection laws, we need to know what data are stored
in the IdM, their purpose, a legal base for their storage and
where they might be provisioned to. Within <a
href="https://docs.evolveum.com/midpoint/midprivacy/">midPrivacy
initiative</a>, Evolveum is continuously improving midPoint
capabilities to handle metadata for several use-cases, including
supporting privacy-preserving features. The ultimate goal is to
have such metadata tied to the primary attributes of users and be
able to use them consistently across various use-cases, where
just-in-time provisioning is clearly one of them.</p>
<p>Attribute release aside, there is one more thing that we can do
for authorization. For services that we know, typically local
services within own institution, the access management can decide
if a particular user is authorized to sign in to a service or not.
The IdM is the ideal source of such information because it
contains all information about roles, groups and accesses. There
are several benefits of making the decision centrally instead of
deciding on a service level based on attributes. The first one is
aggregating information in a single place, which can help with
internal audits or can be used as a tool for helpdesk that can
verify accesses of any user. The second one is user experience.
Having authorization decisions on a central level enables
consistent user experience in case access is denied. Furthermore,
users can be pointed out to possible solutions. For example, offer
them a link where they can apply for access. Access requests and
approvals are features that identity management can also handle.
You can check <a
href="https://docs.evolveum.com/midpoint/reference/cases/approval/">Evolveum
Docs</a> for ideas.</p>
<p><strong>Just in case provisioning</strong></p>
<p>Just in time provisioning also have its own disadvantages.
Accounts can be created or updated only when a user is signing in.
Deleting accounts is practically impossible because users won’t
typically sign in to the service when their account is no longer
valid there. Not having regular updates might lower user
experience of using services where users are interacting with each
other. Without updates there may be old data that are no longer
valid.</p>
<p>These disadvantages can be overcome with just in case
provisioning. On these terms, the central identity management
system has all information about users and their accounts and
accesses. Therefore, it can provision any change immediately when
it occurres. MidPoint provisioning is doing precisely that. The
whole midPoint, including provisioning, is based on delta updates.
Each delta contains a changeset on a single object, which is
immediately processed, and derived provisioning operations are
immediately executed. Thanks to that, you can be sure that any
simple operation performed in midPoint GUI or via REST API is
provisioned to resources by the time you get the response from GUI
or API. This approach addresses the typical doubt that some people
are having about just in time provisioning, which is its speed in
comparison with just in time strategy. Complex operations which
affect multiple objects are processed in the background using
tasks. The reason for that is the operation may take even several
hours or even days to complete if it is complex enough. The tasks
allowed us to monitor the progress of the execution and also to
optimize it. MidPoint supports parallel execution of a task in
multiple threads or even processing a task on multiple nodes,
which might scale the processing to fit the requirements.</p>
<p>In the second part of this blog post we will talk about
provisioning performance, messaging and reconciliation.</p>
<p>(Reposted from <a
href="https://evolveum.com/midpoint-in-higher-education-provisioning-deprovisioning-and-synchronization-part-i/"
moz-do-not-send="true">Evolveum blog</a>)</p>
<pre>--
Slavek Licehammer
</pre>
</body>
</html>