Focus Processing

Data that flow into midPoint are seldom complete and clean. Quite the contrary. The data coming from the "feeds" are often incomplete, they are not very precise, and sometimes several sources may not even agree on a value for a particular data item. Inbound mappings can be used to sort out some of these problems. However, inbound mappings are designed to work in isolation. They work only for one particular resource and one particular attribute. We often need to gather data from several resources, and then look at all of them at once. Inbound mappings cannot do that very well, as they are tied to the resource. However, inbound mappings can be used to gather all the relevant data in the user object. Then we can have a look at user object, where those data are gathered, and process them all together. That is what object templates do. Object template can be used to do variety of things to all kinds of midPoint objects.

Simply speaking, object template is a set of definitions and mappings that is applied to a particular midPoint object. For example, user template is applied to all user objects. The mappings in the object template can produce new values for the object. For instance, a very typical use of object template is computation of user’s full name:

The mapping above computes the value of user’s fullName property from givenName and familyName by using a simple Groovy expression. It is a weak mapping, therefore it computes the full name only in case that it is not present already.

Import of object template definition into midPoint does not do much. The template is not used yet, it just stored in midPoint repository. There can be several object templates for different types of objects, archetypes or organizations at the same time. MidPoint does not know how to use the template, unless it is specified in a configuration. The simplest and most common way to use an object template is to configure use in the archetype.

Alternatively, object template can be configured globally in system configuration object:

This configuration activates the object template for use by all objects of UserType type. Therefore, this template is applied to all midPoint users.

Even though object templates can be set globally, it is usually better to apply object template using archetypes. Use of archetypes provides finer control over content of individual objects. E.g. we want to generate full name by concatenating given name and family name for persons (users with Person archetype), yet we do not want to do that for non-person users (such as administrator).

Object template is applied every time an object is created, changed or explicitly recomputed (e.g. on reconciliation). Object template is applied after all the inbound mappings are processed. Inbound mappings often copy important data to the object, therefore the template can work on data that are summarized from all the resources.

In traditional role-based access control (RBAC) models, roles are supposed to be manually assigned to users. That’s the whole point of traditional RBAC: simplify access control by using roles instead of low-level permissions. However, current access control models are all but traditional - they can be described as flexible, dynamic, adaptive, or by any similar term that a marketing team invented yesterday. Whatever are the access control models called, they all rely on dynamism: ability to control privileges automatically as a reaction to changing environments.

Even though midPoint started with role-based access control mechanism, we have always considered this to be dynamic form of RBAC. MidPoint RBAC is not fixed to static roles. Roles can be assigned and unassigned automatically and dynamically. This is a crucial element in all midPoint deployments, therefore this is the right place to describe the mechanisms.

There are some use cases that pop out in identity management solutions all the time. One such case is the problem of finding a unique identifier. This is a concern for almost any type of identifier, but it is particularly painful when it comes to usernames. In midPoint world, this means finding a value for name property. This property must be unique for almost all the data types that midPoint supports.

The rational way would be to base usernames on something that is already unique and immutable such as employee numbers or student identifiers. However, those tend to be long numbers, and people often hate them. Therefore, many deployments chose to base usernames on real names of the user. We can easily generate username for Alice Anderson. Maybe aanderson would be a good fit? It is nice, easy to remember and reasonably unique. We can do that with a simple object template mapping:

This can indeed work quite well - until Albert Anderson is hired. Then we need to get creative. Obviously, alanderson will not work here. What about alianderson and albanderson? Oh no, we have this ancient application in our company. That application allows only ten characters in the username, and alianderson is just too long. What is even worse, we would need to change Alice’s username for this to work. She will get really mad about it. Not to mention that if we go on with this scheme, we may need to change usernames for pretty much everybody, eventually. That won’t do. Let’s go the usual way. Let’s have aanderson and aanderson1. It is not entirely elegant, but it will do the job. Even better, Alice will not get mad. You know, she is really scary when she gets mad.

This use case is so common that even very early midPoint versions supported it. This feature is called iteration in midPoint terminology. The name suggests how the mechanism works. First step is an attempt to create a user object in a perfectly normal way. This means that username aanderson is generated for Albert Anderson. Then midPoint checks if that username is unique. In this case the username is not unique, as it is already taken by Alice. That is the point when midPoint starts iterating. MidPoint creates iteration token. Iteration token is a short string that changes in every iteration. In our case, the iteration token is initially set to 1. Then midPoint re-evaluates all the object template mappings. Mappings that are supposed to create unique values need to use that token. They should look like this:

When this mapping is evaluated for the first time, the iteration token is empty. Therefore, it will make no difference for the normal processing. When the mappings are re-iterated, the token is set to 1. Result of this mapping is aanderson1, which is unique username. Therefore, iteration stops there and normal processing continues. In case that even aanderson1 is not unique, the iteration continues. Usernames aanderson2, aanderson3 and other variants are tried. The iteration continues until a unique username is found, or until iteration limit is reached.

Iteration functionality is disabled by default. Therefore, any conflict in username will result in hard error. This makes sense, as no amount of iterations will make any difference until the iteration token is used in the expressions. We also want to set maximum number of iterations. E.g. there may be a bug in the mappings that may cause endless iterations. The iteration functionality can be enabled by specifying iterationSpecification element and setting iteration limit:

Iteration tokens are strings that are created from iteration number. It is the iteration number that really matters for midPoint. Iteration token can take variety of forms, it can be numeric, it may be alphanumeric, fixed length, variable length or anything else. Some mappings will not use the token at all. E.g. mappings that subsequently add letters from given name to the username. Therefore, both iteration number and iteration token are exposed to the mappings. There are two variables:

There is default algorithm that derives iteration tokens from iteration number. The algorithm is illustrated in following table.

The algorithm is designed to put empty value in the iterationToken during normal processing. The idea is that iterationToken variable can be safely used both for the normal processing and for the iterations. This is just a default algorithm, and it is certainly not going to fit all the deployments. Therefore, a custom mechanism to derive iteration token can be specified. For example, we may not like to have aanderson and aanderson1. Which one of these is number one and which is number two anyway? Let’s skip aanderson1 and let’s use aanderson2 for the first iteration. The iteration number cannot be changed as the iteration sequence is fixed. However, there is no problem for iteration 1 to produce iteration token "2". This can be achieved by specifying a custom algorithm for the token:

This algorithm will produce sequence of aanderson, aanderson2, aanderson3 and so on.

Iteration number and iteration token is the same for the entire object template. All the mappings see the same value and all the mappings are recomputed when there is a need to re-iterate. Therefore, iteration token is not limited to username, it can be used in other mappings too. For example, use of the token in e-mail address is a very common case:

This mapping produces a sequence of albert.anderson@example.com, albert.anderson2@example.com, albert.anderson3@example.com and so on (assuming that customized token expression is also applied). Shared value of iterationToken means that the values of e-mail address are consistent with the values of username. If username of aanderson2 is generated, then the e-mail address is albert.anderson2@example.com. The same iteration token is used.

However, it all becomes interesting when it comes to e-mail addresses and other identifiers that are publicly exposed. It is one thing to have username aanderson2. That username is used to log into the system, but is it not very visible outside the system. However, an e-mail address is exposed to a lot of people. It may be strange to have e-mail address of albert.anderson2@example.com, while there is no other albert.anderson@example.com in the company. This can be solved by making the mapping for e-mail address smarter. It can ignore the iteration token, and it may try to create an e-mail address on its own. However, in that case it needs to explicitly check for uniqueness. There are two ways to do that. First method is to check for e-mail address uniqueness inside the e-mail mapping. There is a isUniquePropertyValue(…​) method in midPoint function library that is designed for this purpose:

The problem with this approach is that there may be corner cases. We might need to force another iteration even if the username is unique. MidPoint checks only for uniqueness of username by default. However, it is possible that even if aanderson2 username is available, the albert.anderson2@example.com address is already taken. This may be an error in the data, administrator’s mistake, or it may be an artefact of retired Albert Anderson senior who worked in the company years ago, yet his e-mail address was never deprovisioned. The e-mail address mapping can detect this situation. However, what is the mapping supposed to do when it detects a problem? It makes no sense to have username aanderson2, and e-mail address albert.anderson3@example.com or albert.anderson.X@example.com or anything similar. What would make sense is to re-iterate and produce username aanderson3 and e-mail address albert.anderson3@example.com. That would be nice and consistent. However, the mapping cannot do that by itself. Therefore, there is another iteration expression for this purpose: post-iteration condition. It is a condition that gets executed after the iteration is completed. If the condition returns true, then the iteration is accepted as valid, and the generated values are used. If the condition returns false, then midPoint re-iterates and yet another iteration is tried.

The code above does not do much in case the e-mail address is unique. It returns true, the iteration is accepted, and everything goes as usual. In case that the e-mail address is not unique, the code returns false. In that case, midPoint discards all the results of the iteration, increments iteration counter and re-tries the iteration.

There is yet another mechanism that can be used here: pre-iteration condition. It is a condition that is executed prior to iteration. If it returns true, then the iteration continues. If it returns false, then midPoint immediately re-iterates. The difference here is that this condition is executed before all the other mappings are evaluated. Therefore, it may be used to avoid evaluation of expensive mappings just to discard the values that they produce.

When it comes to human-friendly identifiers, there is yet another trouble. People tend to change their minds. They also like to have all kinds of crazy ideas, such as the urge to get married. The result is that the names of people change. In fact, they change surprisingly often. When user-friendly identifiers are used, change in user’s name usually means a change in the identifiers. This is known as the rename problem, and you can observe a glimpse of fear in the eyes of all experienced identity management engineers every time it is mentioned. Overall, midPoint handles renames very well. Primary identifier of any midPoint object is an OID, not a name. OIDs do not change. Therefore, as long as midPoint is concerned, nothing special happens when user’s name is changed. The change is picked up by mappings, recomputed and stored. However, iterations and uniqueness checks may complicate the things here. MidPoint remembers the iteration number for all objects that went through an iteration process. This is necessary to get the same results from the mappings every time that they are recomputed. Otherwise the identifiers may get re-generated on every recompute. However, there is a drawback to this approach. Let’s suppose that Carol Cooper had username ccooper2. She got married and now her name is Carol Cunningham. Even though there is no ccunningham in the system, her generated username will be ccunningham2. The iteration token is remembered and re-used during the rename process. The rename scenarios can be very treacherous. We always recommend to test them thoroughly in any project where user renames are possible.

Another drawback of those iterating algorithms is scalability and performance. Every time there is a conflict, the algorithm need to go through all the iterations that correspond to all the taken usernames. How many people named John Smith can be in a large user population? We can easily get to jsmith42. This means that the next John Smith needs to go through 42 iterations before the system figures out that the next available username is jsmith43. This gets worse with every John Smith added to the system. Therefore, this iterative approach is not suitable for generating identifiers that are likely to require a lot of iterations. Generating UNIX user and group numbers is a good example for identifiers that would surely cause a disaster if an iterative approach is used. Fortunately, there is another mechanism in midPoint that can support generation of such identifiers: sequences. More on that later.

Overall, the best strategy is to avoid using those generated human-friendly identifiers altogether. The best choice would be something that is already unique, immutable and reasonably short. Something like employee number, student identifier or partner ID are usually suitable. If that is not acceptable, then the second-best approach is to keep the algorithms simple. The simpler it is the less likely it is to fail.

It is time to put all the bits and pieces together. So far we have been talking about provisioning, inbound synchronization, schema, RBAC, archetypes and object templates. Let’s see how all the parts fit together:

Everything starts with a synchronization process, whether it is reconciliation or live synchronization. Synchronization process invokes the connector for the source resource (Resource A). The connector retrieves the data from the source system. Shadow objects are created for all the source accounts as soon as the data set foot in midPoint. Correlation is evaluated for all new accounts to find their owners. Once we have owner of the account, we can execute inbound mappings. This is the way how account data are reflected to midPoint user object, which is a focus of the computation.

Next couple of steps is all about the focus. This is the part where object templates are executed, assignments and roles are evaluated. Assignments and roles may contain construction statements. Those statements are just collected at this stage. They are not evaluated yet. This focus policy phase of computation is all about the focus. Which means that user object is both the input and output of this computation.

Outbound phase takes place next. In this phase, the focus of the computation (user) is projected to accounts. This is the time when constructions are processed and the mappings inside them are evaluated. Those constructions were collected from the assignments in the previous phase. They are combined with outbound mappings specified in resource schema handling. All of that is mixed together, sorted to resource accounts, all the values are computed. This is also the time when attribute-level reconciliation takes place. We know what attributes the account should have, therefore we can compare that with the values that the attributes have in reality. When all of that is computed and processed, then a connector is used to update the target resource (Resource B).

This picture is still not entirely complete. It does not show policy rules, existence mappings, approval processes, hooks and good deal of other advanced features. Yet, this picture is good enough for now. It is good enough to create a simple, yet complete solution.

We have all that we need to create a simple but mostly complete identity management solution. Our environment and solution outline:

We can do that if we put together all that we have learned so far. Even though this is still quite a simple example, the complete configuration is too large to put all of it into this book. It will take too much space. Moreover, after all the detailed explanation in the previous chapters, it would also get a bit boring. Therefore, we will show only the interesting pieces of the configuration here. Complete configuration can be found in the usual place. Please see Additional Information chapter for details. These files represent the final configuration, the expected state at the end of this chapter. Therefore, if you want to follow instructions in this chapter step-by-step, you have to choose appropriate parts of the files to import. Alternatively, you can just import everything, and use the following text as an explanation of the effects that you see.

Let us start with an HR resource. This is mostly the same resource definition as we have seen in the Synchronization chapter. However, there are few differences. First of all, the data feed is a bit different. We have a new jobcode column there. It looks like this:

Of course, the HR resource definition has to reflect those changes. We have defined a new custom user property jobCode in our extension schema:

The jobcode column is mapped to jobCode extension property in HR resource inbound mapping:

There is one more interesting inbound mapping, a mapping that automatically assigns Employee role. All the records that come from the HR resource are employee records. Therefore, we want to assign Employee role to all of them. The easiest way to do that is to use inbound mapping of HR resource:

This mapping is quite straightforward. Its expression produces a static targetRef value that is placed in user’s assignment. The strange thing here is the placement of this mapping. It is placed in the section that corresponds to empno attribute. This is inbound mapping, and it just has to be placed somewhere. Any reasonable attribute would do. It does not really matter into which attribute it is placed as it ignores attribute value anyway.

The rest of the mappings that are defined in the HR resource is a bit boring. The interesting thing is the mapping that is not there at all. The mapping for username (property name of the user object) is missing. We are not generating username in the inbound phase. We just do not have enough data to responsibly generate username just yet. Inbound phase is still running, user object is not fully populated yet. Let’s postpone the decision about username for later.

Synchronization part of the HR resource definition is also a pretty standard one. This resource is an authoritative source. Accounts are correlated by the empno column matching the personalNumber user property. Linked accounts are updated and new users are created for unmatched accounts. It is all the same routine as we have already described in Synchronization chapter.

Perhaps the most interesting part of this setup is object template. The template has several responsibilities:

All our users originating from the HR system have Person archetype. This is quite a standard configuration, and it is a very suitable one. We want to set up object template for users that represent persons. We do not want the template to apply to system users, such as administrator. Therefore, Person archetype is an ideal place to specify the template. This configuration is so common, that this is already pre-configured in midPoint. There is Person Object Template which is present in midPoint by default and it is already applied to Person archetype. All we need to do is to modify that template.

Let’s start with the simple thing: generating full name. At this point this almost a no-brainer:

This is almost the same mapping as we have seen before. However, there is one difference: concatName function is used to concatenate the names. The concatName is quite smart, it converts all inputs to strings, it trims them, handles cases where some parts of name are null or empty - overall, it saves a lot of trouble. Perhaps the most interesting thing about this mapping is the fact, that it is already present in Person Object Template by default. We do not need to change anything.

Full name mapping is really simple, but it is a bit harder for username. We want to generate a user-friendly username. We could simply use user’s last name, but this is very likely to create conflicts. Therefore, let’s combine last name with the first letter of first name. That gives us nice usernames such as aanderson, bbrown and so on. However, there is still a chance of username conflict. So let’s add iteration tokens into the mix. Like this:

This looks a bit more complicated that your have expected, doesn’t it? The basic idea is simple, so why won’t equally simple expression work? Maybe something like this?

The devil is, as usual, in the details.

Firstly, good part of any programming is robustness and error handling. All the stringify and trim functions deal with inputs that are null, formatted in a wrong way (e.g. extra spaces) or wrong data types (e.g. polystring instead of string). We are also making sure there are no spaces in username (hence the replaceAll function).

Secondly, midPoint is built with multinational environment in mind. It is 21^st century already and Unicode is everywhere. Almost everywhere, that is. It is expected that the HR system stores names with full national characters, such as Radovan Semančík. Yet, it is still not a common practice to use national characters in usernames, e-mail addresses and so on. Therefore, we usually want to normalize the national characters to their ASCII-7 equivalents. That is what PolyString is for and that is what the norm methods are doing. The result is that the generated username will be rsemanci instead of RSemančí.

Then there is slightly annoying issue of legacy in information technologies. Even though it is 21^st century already, some systems are still quite behind. For example, sAMAccountName identifier in Active Directory is limited to 10 characters in length. Therefore, we are limiting the length of username to 8 characters, leaving last two characters for the iteration token. This is what the take(8) function does.

The bad news is that reality always finds a way to bring surprises, therefore the expressions dealing with real-wold data need to be more complicated than it is perhaps expected. However, there is also good news - at least when it comes to username generator mapping. The mapping above is already pre-configured in default Person Object Template in midPoint. It is not enabled by default. Lifecycle state of the mapping is set to draft, which effectively inactivates the mapping. Changing the lifecycle state to active enables it, and makes it ready to be used.

However, there is still one piece missing. We want to enable iteration to resolve naming conflicts. Otherwise poor Albert Anderson won’t have his accounts created because aanderso username is already taken by Alice. We can enable iterations like this:

The maxIteration part up there is quite straightforward. We want to have some limit on the number of iterations as we do not want to iterate forever. Most iteration sequences are short in practice. If the iterative approach cannot find a match in several steps, then perhaps the iteration is not a good method anyway. Therefore, the limit is usually not a problem. However, having a limit makes a huge difference for troubleshooting. Most infinite iteration loops are caused by configuration errors. It is way much better to get an error after a couple of seconds than to wait forever.

The second part of the iteration configuration is also quite clear for people that read this chapter carefully. The default iteration token sequence is "", "1", "2", "3" and so on. That would give us aanderso, aanderso1, aanderso2 and so on. We do not want to have aanderso and aanderso1 as that would be confusing. Therefore, we chose to skip the "1" token and start with "2". The custom iteration token expression does just that.

Similarly to the mappings, iteration specification is already part of default Person Object Template.

As soon as the above configuration is in place, we can start testing our little deployment. Go ahead and import the HR resource, import object template, set the object template in the configuration and do not forget to replace the HR CSV file. If you did any experiments with previous configuration, it can be helpful to clean up midPoint by using the "delete all identities" process (that little dropdown button in menu:Repository objects[] page). When everything is set up, you can try to manually import a single account from the HR resource by using the btn:import[] button, located on the page where you can list resource accounts. Once the basic configuration works, you can test username generator by adding Albert Anderson to the HR CSV file and importing the account. Do not forget to explicitly fetch the accounts from the resource by clicking on the btn:Reload[] button on the bottom of the page. There is no synchronization task running, therefore MidPoint have not seen Albert’s account yet. You have to instruct midPoint to explicitly look at the resource. Once Albert’s account is imported, a non-conflicting username should be generated for him:

We need to generate e-mail address next. In our case, the mapping for e-mail address is a bit similar to username mapping:

This mapping should be quite understandable by now. There are the same checks for special cases. Then the main expression at the end combines given name and family name to get an e-mail address. This is just a simple example for e-mail address that is a good fit for a book or for a simple deployment. However, dealing with e-mail address is a bit more difficult in practice. A clever reader can surely discover a couple of obvious issues. Firstly, the expression is using the same iteration token than the username mapping is using. Therefore, the e-mail address for Albert Anderson will be albert.anderson2@example.com.

This is what we get when we re-import or reconcile both Andersons:

This is not exactly what we want. Ideally, we would like to use much simpler versions albert.anderson@example.com. In this case there is no conflict with alice.anderson@example.com. However, midPoint does not consider e-mail address to be an identifier, therefore it does not check for its uniqueness. Also, there is only one iteration token that is reused for all the expressions in all object template mappings. There are also primary e-mail accounts and account aliases, dealing with account renames and temporary assignment of e-mail aliases and so on. Overall, dealing with e-mail addresses is far from easy. Some of those issues can be solved with pre-iteration or post-iteration conditions. However, it is quite likely that a completely custom code will be needed for a more complex cases.

That is also one of the reasons to set strength of this mapping to weak. We want to set an e-mail address automatically, but only in case that an address was not already specified manually. Weak mapping does not overwrite existing value. Sometimes it is best not to automate everything, leave the complex cases to system administrators to deal with.

Similarly to the full name and username mappings, the mapping for e-mail address is also part of Person Object Template by default.

Role autoassignment is the next step. We are going to handle role autoassignment based on job code using the object template method described above. Our object template works with user object both as input and output. It cannot (or rather should not) reach out to the HR account to get the value of jobcode attribute. We have to do that the other way around. We have to map HR account attribute jobcode to midPoint user property jobCode by using an inbound mapping:

As the job code is synchronized to user, we can easily use it in object template mapping now:

This is the same principle as we have used earlier in this chapter. The mapping is using assignmentTargetSearch expression to look for roles where user’s jobCode and role’s autoassignJobCode match. This mapping is strong, as we want to recompute the mapping and set the value all the times. If the mapping would be normal-strength, then the values are recomputed only when jobCode changes. Which actually might be enough during normal operation of the system. However, making this mapping strong makes things much easier during testing. That is all that we need to do for the mapping. Now we need to prepare the roles for this mapping to work with. We need to extend role schema first:

Then we need a couple of roles with job codes in their extension:

That is all the configuration needed for autoassignment to work. The roles should be automatically assigned to users when the users are recomputed. Just make sure that the users have their jobCode properly set in the user object. If they do not have it, then re-import them from the HR resource or run a reconciliation task. Then go ahead and create some more roles for the missing job codes. The mappings do not need to be changed at all to support more job codes. Just create new roles and recompute. That is the beauty of this solution - it is so easy to maintain.

So far we have tackled the inbound phase and focus policy phase. However, we have not talked about the outbound (provisioning) phase much. Now it is the right time to have a look at that.

We are going to reuse the LDAP and CRM resources from previous chapters. Those resources are used here in a pretty much unchanged form. There is no need to change them. Outbound mappings in the resource definitions specify the basic framework of the account. The key to provisioning flexibility is usually not in the resource definition, it is in the roles. Let’s start in the simplest way possible - with the Employee role. ExAmPLE company policy states that every employee should have a very basic LDAP account. Therefore, all we need is a very simple LDAP account construction that we place into an inducement in the Employee role:

All employees get this role, by the means of inbound mapping defined for HR resource. Therefore, all employees automatically get basic LDAP account. It is as simple as that. Put the construction in the role, reconcile the HR resource or just recompute the users, then LDAP accounts are created for all employees.

We want something a bit more fancy next. Salespeople tend to be a bit sensitive when it comes to their professional image. Therefore, they insist on having proper titles set up in company directory. Not a problem. We can do that easily in their "job" roles. This is how it looks like for a sales manager:

This construction refers to the same account as the Employee role. MidPoint knows that, therefore it does not attempt to create a new account. It just updates existing account with appropriate title. However, we are not done yet. We need to provide access to CRM system for the salespeople. Should we create a new role for that? Absolutely not. We do not want to have too many roles as every role is a maintenance burden. Let’s just add new construction to an existing job role:

This is a role that gives access to the CRM system for a sales manager. MidPoint knows that, and it automatically creates a new CRM account when the role is assigned. Outbound mappings from the CRM resource definition are used to set basic properties of CRM account, such as account identifiers and password. In addition to that, the Sales Manager role sets appropriate access level to the CRM system.

Our setup is almost complete now. We have inbound synchronization, object template, roles and outbound mappings. This is the right time to test everything. Select few representative HR accounts and try to import them. Check that everything is provisioned correctly. If it works, then it is the time for roll-out. Set up a synchronization task for the HR resource, and we are done. We have running system:

Users are imported from the HR system. Roles are assigned, which can be checked by navigating to user details page and opening the menu:Assignements[] tab. Accounts are provisioned according to the roles, which is the reason for variations in number of accounts for individual users. The basic stuff works now. Go ahead and try it out, add more roles and mappings, modify the configuration. Have some fun.

Even this simple identity management deployment is a huge improvement for many organizations already. However, there is still a lot of things to improve here. Maybe we want to set up a formalized organizational structure. Maybe we need delegated administration. We almost certainly want to manage groups, privileges and other entitlements. This is still just a beginning.

This chapter concludes one whole part of the book. If you have followed the book so far, you should be able to set up a simple working identity management deployment at this point. We have covered all the basic mechanisms: resources, mappings, roles, schema and object templates. This is a good time to stop reading and get your hands dirty. Take the examples from this book and play a bit with them. Explore the examples that come with midPoint distribution. Watch videos on Evolveum YouTube channel. Now it is time for experiments. You will surely do a lot of things that are suboptimal or even outright wrong. That does not really matter now. This is part of the learning process. If you get to dead end, just scrap everything and start over, or maybe rework everything from the ground up. MidPoint is designed for this. Evolutionary approach is deeply embedded in midPoint philosophy and design. Just go ahead, have fun, conduct experiments and explore. Such experience will help a lot when you get back and read through following chapters.