<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/30/2013 04:10 PM,
Belleville-Rioux, Vincent wrote:<br>
</div>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D00367E1@Lettre.gst.uqam.ca"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style type="text/css" id="owaParaStyle"></style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">
<div>We have about 10k new students each semester and also have
about the same number of students that get "offboarded" from
some services due to various reasons.</div>
<div><br>
</div>
<div>What we're trying to evaluate is how we could automate such
state changes so we can do something like :</div>
<div><br>
</div>
<div>- 1 month before the start of the semester, all students
registered to at least one class will get their account
created / activated. A notification message will be sent.</div>
<div><br>
</div>
<div>- 12 months after the end of the last semester where the
student had at least one class, the account will be
deactivated and a notification message will be sent.</div>
</div>
</blockquote>
<br>
This is quite common scenario both in enterprise and academia. And
this was actually a reason to create time-based mappings. Therefore
it should work even in v2.2 but the limitation is that is should be
applied to the entire account and not just a single role. The basic
idea is like this:<br>
<br>
MidPoint user will be created in midPoint as soon as we know about
such record. E.g. it can be synchronized from HR (or any equivalent
academic source system). The key idea is that user's validFrom date
will be set to onboarding date (or hire date or sunrise date or
whateverYouCallIt ;-). The activation administrativeStatus of the
user should be empty (null). This will cause that midPoint will
compute effective user activation status based on validFrom, validTo
and current date.<br>
<br>
Assign any roles to the user, e.g. using an object template. The
roles should represent a state of the user as it should look like
during semester. You do not need to specify any conditions in the
object template mappings nor any conditions in the role outbound
mappings. The roles can be assigned anytime, even before semester.<br>
<br>
Define a time-based activation mapping for the resources that you
want to "pre-provision" or for whose you want to delay
de-provisioning. An example is here:
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/Resource+Schema+Handling%3A+Activation">https://wiki.evolveum.com/display/midPoint/Resource+Schema+Handling%3A+Activation</a>
(see "Mapping Time Constraints" section).<br>
<br>
And that's it. Before the semester the user has all the roles, but
as the time is before user's validFrom the activation mapping in the
resource definitions will not be used and the accounts will not be
created. When the semester starts the time passes through validFrom.
MidPoint detects that (automatically) and the mapping will be
evaluated differently. The accounts will get created. And similar
mechanism also applies to delayed deprovisioning. The examples are
actually slightly more complex than your requirement as they are set
up to create a disabled account 5 days before onboarding and then
enable it right on the onboarding date.<br>
<br>
The current limitation is that this applies to all accounts on the
resource. If you want to apply it only to some accounts you have to
play with the mapping conditions. This may be tricky but it should
work. However, this is not the ideal way how to create maintainable
system. Therefore we plan couple of improvements:<br>
1: support account types (this is called "intent" in midPoint
terminology), e.g. account type "user", "student", "admin",
"tester", .... you can specify different mappings for each type.
Most of the work on this feature is already done. But nobody stated
that this is important enough to give us enough motivation to
finally complete and test it. :-)<br>
2: support similar time-based mappings in assignment/inducement
conditions. In such a case you can specify this behaviour per role.
This is slightly more difficult to finish, but still possible.<br>
<br>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D00367E1@Lettre.gst.uqam.ca"
type="cite">
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">
<div>The startDate and endDate are properties we can read from
an SQL table (but I'm simulating that with a CSV file for
now). I guess we'll have to reconcile at least once a day
because that table will have updates to those dates as
students use our online tools to register / unregister
themselves to classes.<br>
</div>
</div>
</blockquote>
<br>
If it is really a DB table and it has a timestamp column you may
rely on livesync instead. It is more efficient and much faster. Use
reconciliation just as a "last instance" in case that livesync
missed something (e.g. due to bug in mapping script, because the
system was down for a long time, etc.)<br>
MidPoint is designed to use livesync as a primary mechanism as often
as possible and use reconciliation only as a "safety net".<br>
<br>
Anyway, unlike some other IDM systems midPoint configuration is
almost entirely the same whether you use livesync or reconciliation.
Therefore it is easy to experiment with it and fine-tune the setup
that works for you.<br>
<br>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D00367E1@Lettre.gst.uqam.ca"
type="cite">
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">
<div>We should also have the ability to override those values
with other dates like "bannedOn" or "temporaryExtension" :</div>
<div><br>
</div>
<div>The bannedOn date would make any student which has that
date as a non-null value be kept inactive for 7 years from
that date.</div>
<div><br>
</div>
<div>The temporaryExtension date would make any student account
active for 12 months from that date, regardless of the endDate
imported from SQL.</div>
</div>
</blockquote>
<br>
Interesting requirement. Really. I quite like it :-) And I guess you
can implement this behaviour by using the correct conditions in
activation mappings. I quite wonder how "clean" or maintainable the
result will be though. Anyway, it is worth trying. And if you find
that you cannot do it or that it is unreadable and confusing then
let me know. Maybe we could think about some way how to improve our
mapping code to make it better. Maintainability of the system is
very important for me.<br>
<br>
It is also import for you to realize whether these rules apply to
users (students as physical persons), to accounts, or to assignments
(relation of user to an account). As far as I know it is usual that
a person may be a student on faculty X and work on faculty Y while
the onboarding dates may be different. Then is would be best to
store the dates in assignments. If this is the case then midPoint is
designed to handle situation like this quite well. The system of
"assignments" is designed primarily for this purpose. While most of
the functionality for assignments is already there some pieces of
code may still be missing (e.g. the assignment activation mappings).
Therefore it may be best for you to start with a partial solution
such as storing the dates in users. This can work well for a first
phase of your project. And you can work with us to plan the required
features in the roadmap so you can have it ready for subsequent
phases. IDM projects are not deployed overnight therefore I believe
that we can agree on a reasonable delivery dates that can work for
you.<br>
<br>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D00367E1@Lettre.gst.uqam.ca"
type="cite">
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">
<div>So, as you can see, dates are really useful for our use
cases. I understand that this was added rather quickly to
2.2. Would you suggest we upgrade our test environment to the
latest snapshots and try and follow the development from there
on?</div>
</div>
</blockquote>
<br>
Not yet :-) .. if you decide to use time-based activation mappings
then it should work well in 2.2. If you find some bug in this part
we will fix it in 2.2.1 as this is important feature. If you decide
that you need more than activation mappings then there is no point
to switching to the development branch yet. The code is not yet
there. In such a case please let us know and we will figure out when
we can deliver that. But I quite believe that activation mappings
are almost entirely what you need now. And once you have your first
version working we can talk about how to improve it in the future.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
</body>
</html>