[midPoint] RE : RE : RE : RE : RE : Namespace problem

[Radovan Semancik]

On 09/30/2013 04:10 PM, Belleville-Rioux, Vincent wrote:
> 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.
>
> What we're trying to evaluate is how we could automate such state 
> changes so we can do something like :
>
> - 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.
>
> - 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.

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:

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.

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.

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: 
https://wiki.evolveum.com/display/midPoint/Resource+Schema+Handling%3A+Activation 
(see "Mapping Time Constraints" section).

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.

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:
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. :-)
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.

> 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.

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.)
MidPoint is designed to use livesync as a primary mechanism as often as 
possible and use reconciliation only as a "safety net".

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.

> We should also have the ability to override those values with other 
> dates like "bannedOn" or "temporaryExtension" :
>
> 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.
>
> The temporaryExtension date would make any student account active for 
> 12 months from that date, regardless of the endDate imported from SQL.

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.

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.

> 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?

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.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20130930/c38c0c66/attachment.htm>