First Steps With MidPoint: Current Situation
Summary of what is happening before they go for a solution like midPoint, what are they typical activities, what are the struggles.
Automatic scripts, on-demand executed scripts or manual intervention is used to support provisioning. The processes are usually managed using tickets (or e-mails, in worst case). Automation is partial, because is usually limited to the accounts and not to users (account owners). Scripts are usually used "as is", they can be created by people no longer working in the company. In that case, script modification/improvements can be costly. Scripts can be executed in an automatic way = scheduled, if there is some connection to HR system. On-demand executed scripts rely on decisions tracked in ticketing system.
Reaction to security incidents (e.g. bad leaver) can take long time (ticket) or may require non-systematic solution (urgent phone call and later ticket - for evidence).
Account rename may be painful: some systems do not support rename at all, other require change of many attributes (e.g. AD: sn, cn, dn, userPrincipalName, sAMAccountName, mail / proxyAddresses including previous e-mail value as an alias…)
For leavers, some accounts are immediately deleted, some are disabled and/or moved within the directory tree and deferred actions need to be executed (allowing user’s manager to access the mailbox, delayed delete, …)
TODO yet more
Typical analysis process
The typical analysis is very limited in scope. It is mostly scratching the surface.
They are thinking about HR records as clean identities. Mostly thinking about people first, last names and how they are identified (not correlated). Some are identifying by employee numbers. When connecting (correlating) records, even when employee number is entered into systems, there are typos or forgotten. Sometimes they are identifying by first and last names or by loginname at best.
They are thinking about target system accounts, usually not as accounts owned by some users. The accounts are managed by administrators of that resource or support teams, their management is often isolated from the other provisioning teams. There might be long unused (orphaned) accounts mixed with service and testing accounts. Some scenarios are resolved "when they happen", e.g. what to do if account name is already taken.
Obstacles (Problem Definition)
Why midPoint in its current state does not satisfy target customers?
Overall (high-level) obstacles:
-
High entry barrier. Customer engineers have to learn too much. They won’t. They do not have time/resources/skills for that.
High entry barrier makes midPoint expensive to deploy and operate, as skilled people need to find a lot of time to dedicate midPoint. This ruins the business case for midPoint deployment, i.e. midPoint total cost of ownership (TCO) is too high.
Questions: Can partners help? Can the customer afford assistance of partner? Is that enough? E.g. will partner operate the system after deployment?
-
Missing methodology. We do not have clear, simple and consistent set of instruction to deploy and use midPoint. MidPoint is a chameleon, adapting to many situations. This is confusing the engineers, they do not know what to do, where to start.
-
Old world vs new world. MidPoint is designed for old world (servers, on-premise, integration, customization, scripting). Yet, there is a brave new world (cloud, services, plug-and-play drag-and-drop do-it-all as a service). Some midPoint concepts fit well in the new world (e.g. git/devops/JSON), others do not (complexity, need for customization).
-
Abstract thinking: MidPoint requires abstract thinking. Understanding to many abstract concepts (focus, shadow, abstract roles, assignments/inducements, policy rules) is essential to use midPoint efficiently. However, this is too much to be handles by most engineers. IT is much more complex than 10 years ago, engineers do not have time to understand each system intimately. The result is that vast majority engineers that work with midPoint will not have sufficient understanding of the underlying concepts. How to make them efficient even with such limited understanding?
Technological (low-level) obstacles:
-
Terminology: MidPoint has its own vocabulary (shadow, focus, projection, …), which is not common in IT field. MidPoint has to have its own vocabulary, otherwise we could not develop/maintain it. However, this is an obstacle for engineers. MidPoint is meant to be used by humans (engineers), presentation and usability is important. How to align midPoint development needs with the usage needs?
-
Configuration vs Data: part of the things that we store in midPoint are configuration (e.g. system config), which should be managed by devops configuration management. Other part are data (e.g. users, accounts) that should NOT be managed by version control. However, there is a big gray zone: roles, policy rules, object templates, mappings. It is not clear how to manage the policies.
-
Managing multiple environments: customers usually need to deploy midPoint in multiple environments (e.g.
DEV,TEST,ACC,PROD). This basically means there are multiple midPoint deployments as midPoint inDEVis usually responsible for managing identities inDEVenvironment. Management of configuration and data and their transfer/transformation between environments may be required. E.g. (subset of) identity data fromPRODshould be transferred toACC(after some anonymization) on a regular basis. -
Complexity of schema: There are too many configuration options and possibilities, many of them poorly documented. It is difficult to figure out which option to use when. It is difficult to find that some functionality/feature even exists at all.
-
Data representation (XML/JSON): Engineers are not used to write XML any more. JSON is better, but it is still a problem (see the "schema" problem above). Engineers should be able to do all the common tasks in GUI, without need for XML/JSON.
-
Hard to troubleshoot: Error messages are often incomprehensible for average engineer and require deep understanding of midPoint (ability to analyze stack traces) or extremely large body of experiences from previous troubleshooting attempts (many times hours of trial-and-errors). Typical example: using q:equal (instead of q:ref) when comparing references leads to cryptic ClassCastException or something like that. And there are zillions of similar cases.