This is the second part of the blog about provisioning. In the first part 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.
Provisioning performance
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.
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.
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.
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.
Messaging
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.
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.
Reconciliation
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.
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.
Conclusion
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.