A ship in harbor is safe, but that is not what ships are built for.
TODO
TODO: Siloes may be necessary (Conway’s law). IDM may keep the siloes synchronized.
TODO: intro to I&I. TODO: warn against waterfall big bang projects. It will take years. Plan ahead. Just the intro. More details about the entire cycle in the next chapter.
TODO: IDM projects take a long time, split to iterations TODO: Analyse, plan, prototype, execute, learn, repeat.
TODO: midPoint is built to support this approach, including open source (zero up-front license cost, subscriptions)
you need to know what you want to do.
Cheshire cat: If you do not know where you want to get, then it does not matter which way you go.
Business vs technology: both have to adapt/align.
Purchasing process is often seen as a battle between supplier and customer. That is an efficient method to get a good price. Good for customer, that is. But this is a terrible method if you need to get good result.
We like to see purchasing process as a dialog, as a cooperation rather than a battle. TODO
TODO: RFP process is not ideal, but we have to live with it. Avoid RFP if you can, try to have a dialog.
Writing RFP: Always prioritize the requirements. Real priorities, setting everything to "Critical" will not work. Outline a long-term plan (years) Make the RFP short and efficient. Human resources are limited, especially in IDM. The longer the RFP is, the lower the chance that the good engineers won’t have time to answer. You want perfect IDM solution? But that is extremely expensive. Do you have the money? What IDM solution would be good enough for you?
Answering RFP: Try to find out the priorities (questions). Try to propose iterative approach, even if the requests looks like waterfall. Waterfall does not make sense, such project would fail anyway.
Always do PoC or a prototype. Internally or externally. 2 weeks are usually appropriate.
General: Build up trust. Look at our source code, commits, number of developers, etc. Look at our bugtracking, see how bugs are fixed. Smart small (PoC), grow up.
TODO: trainings (ideally before project) Make sure there is someone that can help you (Evolveum support subscription is not meant for this).
INVOLVE BUSINESS PEOPLE!
TODO: midPoint Studio TODO: ninja TODO: python CLI
TODO: Configuration vs data
TODO: configuration in studio, however still use wizards (new resource, roles)
TODO: Configuration in git
TODO: Why relational database. TODO: Supported relational databases. TODO: universal (hibernate) repository, vs PostgreSQL
Identity connectors are essential components, integrating midPoint with source and target systems.
Connectors to many commercial off-the shelf (COTS) systems are bundled with midPoint, or readily-available as separate open source projects. However, connectors to custom (or heavily customized) systems have to be developed as part of the project.
TODO: business first TODO: start with normal mappings. Switch to strong.
TODO: devel, test and prod environments
TODO: configuration versioning
Info: maintainable solution. First day is the day of the deployment. TODO: you will need to proceed in iterations, it will take years.
TODO: data are always wrong. Always. People will tell you that they have good data. They do not have good data. No data will survive first contact with reality. There will be conflicts. There will be typos, mistakes, inaccuracies. Good portion of data will be out of date.
HR data are usually quite good, but they are also wrong.
Recommendation: proceed slowly. Validate the data before rolling out. INVOLVE BUSINESS PEOPLE!
Therefore, one has to ask the right (detailed) questions and wait for the right (even more detailed) answers.
Asking the right questions is both art and science. Identity management projects are dealing with automating the user management processes which haven’t been automated (or attempted to, or failed to do so) before. Be prepared for a lot of very general, incomplete and inconsistent information. Keep asking.
Listen to the customer. TODO: make sure you understand the (business) goal of the solution INVOLVE BUSINESS PEOPLE!
TODO: sysadmin questionnaires
TODO: Do not expect too much from the questionnaires. You will get a couple of good answers. Most answers will have only partial data, they will not be very precise. Some admins will nor respond at all.
TODO: look at the data, look at HR records, try to figure out how they were created
TODO: Do not try to analyze too much.
People are people.
They say one thing, but the reality is different.
If there is a database column that is supposed to be ASCII7 form of user’s full name, created as concatenation of first and last name, then there is almost certain probability that it contains value Count Félix Teleke of Tölökö III, KBE.
Do not rely on analytical results completely.
Explain star topology again, its benefits.
Explain what common data model means, and why we want it.
How to handle extensions to data model.
-
Take advantage of the star topology of midPoint data flow. Do it like this:
-
Map data from source systems to focus (user), transforming the values to be as close to the common data model as possible.
-
Make sure the focus data are complete and consistent. Use object templates for that. E.g. Make
-
-
Do not go directly from the source to the target. E.g. do not map
givenNameandfamilyNamedirectly tocnLDAP attribute. First mapgivenNameandfamilyNameto user’sfullName, then mapfullNametocn. TODO: explain why: reusingfullNameon many systems. Consistent application of iteration variables. etc. TODO: explain national characters problem, and how polystring can help.
Identifier management is one of the most crucial mechanisms in IDM deployment.
TL;DR: Make sure that identifier management is done in a single system in a consistent way. We strongly suggest that this system is midPoint. Use only ASCII7 alphanumeric characters.
-
If possible, do not delegate check of identifier validity and uniqueness to any other system, unless you are absolutely and unquestionably sure that the algorithm is correct and acceptable for all your existing and future systems. Almost no system has such an algorithm. Systems differ in case sensitivity. Some systems will interpret national characters differently, some systems will consider "Novák" and "Novak" to be the same, other will consider it different, and many will consider "Novák" to be invalid identifier. Some systems will consider global uniqueness, other organization-wide uniqueness, other just local uniqueness of identifier. The system may not have complete and consistent database, which may lead to duplicate identifiers. Many systems will not consider all the special usernames, such as
administratororroot. All of this is will lead to many unexpected problems. Keep identifier management completely under your control. -
Never ever delegate identifier management to two or more systems, unless you are absolutely sure that they are always going to generate disjoint (non-overlapping) identifier sets. It is acceptable to use several identifier management system if each of them has a different namespace (e.g. identifier prefix or suffix). However, never ever use two or more systems if there is any chance that they would generate identifiers that can be potentially considered the same. Make sure that you consider letter case, national characters, whitespaces and all the details. Double check and triple check all the algorithms, make a very deep analysis of all possible cases, be absolutely sure you know what you are doing. And then forget it. Use centralized identifier management anyway, just to be on the safe side. Your future self will thank your present self for that decision.
-
Be very conservative when it comes to identifier format. Be minimalist.
-
Use persistent identifiers (such as student identification number or employee numbers) if you can. This will save you a lot of trouble when it comes to account renames, group management, analysis of audit trails and so on. Unfortunately, people will usually tend to prefer
jsmithrather thanX2325as their username. -
Avoid using national characters in identifier at all cost. Stick to basic ASCII7 alphanumeric characters, possibly with addition of period (
.) or underscore (_) if needed. -
Avoid using full names of people as identifiers. Full names can have several variations, there will be an urge to include national characters, there will be problems with white spaces (Unicode has many characters that represent a space) and so on. Full names are not unique, and they tend to change surprisingly often. Overall, names of people make a terrible identifier. You will get into all kinds of problems. Unfortunately, some systems insist on using full name as an identifier. Most notable among them is Microsoft Active Directory. Brace yourself.
-
-
Bad idea: Creating identifiers by using different "iterators", e.g. username jack123, mail [email protected] Reason: complex to remember, complex to diagnose, complex to configure and troubleshoot Solution: go for [email protected] or even better janderson8 and [email protected].
-
Bad idea: Relying on resources to enforce uniqueness, e.g. assuming that LDAP server or AD will make sure that the identifiers are unique. There are subtle differences, e.g. names with national characters are handled differently. The right way is to manage identifiers in midPoint. Make sure that the identifiers are simple, ASCII-only, no national characters. This may apply to full names as well, as some systems are using full names instead of usernames for identifiers (notably AD).
Perhaps the best strategy is to make all potential identifier values consistent and unique:
| Original Name | Username | E-mail address | Full name in AD |
|---|---|---|---|
John Smith |
|
|
|
Ján Novák |
|
|
|
John Novak |
|
|
TODO: AD full name (cn) has to be unique: "first steps" full name scheme for AD ("John Novak (jnovak3)")
TODO: How to design and create roles.
INVOLVE BUSINESS PEOPLE!
The purpose of IDM is to bridge applications. Construction and entitlement associations can be used instead of application roles. In theory. Although you probably cannot avoid use of application roles entirely, as people will want to request application entitlements directly. At least synchronize them automatically using generic sync.
Application roles may be useful for governance, e.g. maintaining owners of AD groups.
Role types:
-
Business roles: usually map to a job position or responsibility. Should be understandable for non-tech people. Business roles are almost always composed of lower-level roles (technical, application).
-
Technical roles (IT roles): privileges needed for a particular activity, or part of a job. Technical roles should span several target systems, they should contain access to all the systems and all the privileges to carry out a particular action. Technical roles should still be somehow understandable to business people, even though they need to be specialized in particular business area or familiar with a specific technology.
-
Application roles: contain accounts/entitlements from a single application (target system). They are often understandable to IT people. Business people will have only a rough idea what application roles do. Avoid using application roles in IDM system if you can. However, the matter of application roles is complicated. They usually map to accounts/entitlements in target systems one-to-one. Therefore it is easier to use entitlements directly in technical roles. Application roles are often just a maintenance burden, not adding a lot of value just by themselves. However, they may be necessary for role management, e.g. manual role engineering, role mining, etc. Or maybe you have no idea how to set up technical/business roles, and you want to keep track of application role assignment as a very basic form of accountability. Application roles may also be needed in case an access to the system involves more than one resource, e.g. application database record and authorization in AM system (or LDAP group). If you really need application roles, set up an automated synchronization process. Never maintain application roles manually if you can automate.
TODO: examples of role types, maybe rework this into a table.
Applicability of role management/RBAC varies. RBAC is a huge benefit in organizations with regular structures. For example, branch offices of a bank usually have just a handful of work positions with well-defined responsibilities (teller, supervisor, branch manager). Similarly helpdesk departments, manufacturing floors and similar organizations are usually easy to describe using roles. However, when it comes to the same organizations, there are parts of organizational structure that are very hard to decribe using roles. While bank branches are regular, the HQ office is usually completely irregular. Almost every person working for HQ has mixed responsibilities, unique combination of privileges and so on. This does not mean that you should not try to apply roles in such environment. Quite the contrary. Roles are still needed, otherwise there will be no transparency or accountability. However, this is going to be a slow, tedious and never-ending process. It is usually useless to try to model complete jobs or work positions using business roles. However, use of technical roles can still be helpful. Each person is likely to have a unique combination of technical roles, usually assigned using request-and-approval process. However, you will have a record when the role was assigned, who assigned it, and often also a reason for assignment. This is a very valuable asset for re-certification campaigns.
TODO: common practice: Request the same roles as someone else has. This is a good start. But it makes re-certification harder. Never apply request-and-approval without re-certification. Beware of AI. AI is a good tool, but it must not be overused, and there have to be an efficient oversight.
TODO: role explosion, least privilege security theory vs feasibility TODO: organizational changes → role maintenance
TODO: Automatic role assignment, e.g. from the HR data. Remember: the data are always wrong. Have a process to correct mistakes.
TODO: request → approval → assignment → re-certification → unassignment
TODO: Often request same roles as someone else → should create a business/technical role
Avoid assignment of privileges that are the same as a team leader / manager. The boss is likely to have a long history in the company, changing several jobs, accumulating unnecessary privileges. Assigning the same privileges to team members is a good way to systematically increase risk.
Resource-side entitlements: there may be a lot of them. Managing everything is likely to be a complex burden. There will be thousands of privileges, in hundreds of systems. The low-level privileges often needs very intimate understanding of the system/application where they are used, including understanding of the configuration of the application. Identity management team has almost zero chance to get this right.
Try to manage high-level privileges in target systems, such as groups or roles.
Separate the problem into two parts:
-
privileges→groups/roles on resource side: responsibility of system admin
-
user → (IDM) roles → resource-side entitlements (groups/roles): responsibility of IDM team
Choose the right level of abstraction. The "entitlements" should have a business meaning, rather than technological meaning. Such as job, work position, bussiness function, responsibility, ability for meaningful action. E.g. "branch supervisor" rather than "access-list-123"
TODO: clean up your entitlements in the target system. E.g. introduce a consistent naming conventions for groups. If you cannot rename old groups, at least set up conventions and policies for new groups. This is especially important in popular directory services, such as Active Directory or LDAP.
Synchronize application information from authoritative source.
Management of application accounts, lifecycle, password/key change.
Application decomissioning, removing application groups when application is gone.
However, most organizations are not ready for this.
As a minimum:
-
identify application accounts, not to be presented as orphan accounts
-
set owners on application roles.
TODO: quality varies wildly TODO: try to reconstruct the real, practical organizational tree (not the formal one).
TODO: avoid user-manager method
TODO: removing excessive access TODO: usually the last defense against role accumulation TODO: laborious process, has to be distributed
Beware of AI. It is especially dangerous for certificatin campaigns, as they are usually the last defense against privilege accumulation. If you use AI for re-certification, you will need to have automated risk management in place, to provide additional layer of defense.
The best approach is to keep the amount of re-certification to a minimum. Minimize the number of roles that people have to request, this will also minimize the amount of assignments the certifiers have to review.
TODO: ad-hoc re-certification, e.g. after org assignment change.
Frequent campaigns (e.g. quarterly) vs "triggered" re-certification:
Frequent campaigns are big problem. People will ge tired, won’t pay attention, will certify everything. The result will be useless. Avoid frequent campaigns. Try to be smarter. Have annual campaigns, well distributed, keep the work of any individual certifier low. Use "triggered" (ad-hoc) re-certification, e.g. in case of organizational assignment changes, employee status changes, risk of individual user raises beyond a threshold, certification of outliers, etc.
TODO: This is not a project, it is a program (see later). Proceed in steps, iterations, increments.
TODO: Good communication is absolutely essential. Required information is seldom documented. Difficulty for remote projects.
INVOLVE BUSINESS PEOPLE!
-
Assuming that all the systems will be fully compliant with standards. E.g. there is pracically no LDAP server deployment that is fully compliant with LDAP standard (see LDAP Survival Guide).
-
TODO: user-user manager relation as bad practice. Use orgtree instead.
Application inventory
Onboarding/offboarding porcesses (joiner-mover-leaver).
Processes: Contrary to the popular opinion, IDM is not about processes. It is all abound data and policies. Processes are human concept. E.g. we do not have approval "process", we have approval policy. Sequence of approval steps is computed dynamically.
Plan ahead, especially if you need new features. MidPoint has 6 months development cycles. The backlog has years and years worth of improvements ideas, therefore it is perhaps quite natural that roadmap is a bit overcrowded. It takes some planning to get your features on midPoint roadmap, even if you have the funds for their development.
Even bugfixes can take weeks to months to get fixed. Plan ahead. Test early. Proceed in iterations.
TODO: warn against over-use of AI
Data sources:
(Business to Employee, B2E) HR system is usually a good start. Look for data sources for contractors & temporary workers. You may not find any. Consider that IDM may become the source.
Look for organizational structure sources. You will probably find several sources, all of them useless. It would either not reflect reality, or it will not be machine-processable. Most likely both.
(Business to Business, B2B) Look for data source for partners. In fact, you are looking for two data sources:
-
Partner organizations
-
Partner users (employees/contractors of partners)
You would like for the partner user data to come (directly or indirectly) from partner’s HR system. Two options:
-
SSO/Federation, just in time provisioning, deprovisioning problem, etc.
-
Delegated administration
Most likely, you will need both.
You may need a "sponsor" for each partner or even user. Sponsor is your employee/contractor that is responsible for the partner/user.
TODO: Academia, distributed research teams, vitual organizations, all that mess.
(Business to Consumer/Customer/Citizen, B2C, CIAM) Usually on a bigger scale. Needs scalability. Less value per identity, needs cost-efficient solution.
Different lifecycle, usually governed by the user rather than given by the organization. Self-service is a must.
Data protection and privacy very important.
Do not automate everything. It is too much work, too much maintenance. Prioritize. Automate frequently-used systems (large populations). Automate frequently-changed systems (fluctuation). Automate sensitive systems (seucirity, accountability). Automate day-one systems (mail, productivity). Automate systems that generate helpdesk load.
However, think about security and accountibility. Semi-manual approach may be a good compromise (CSV exports).
Avoid storing passwords in IDM, if you can.
Inconsistent password policies. The best way is to make them as consistent as possible, work with security team.
Good use of AI:
-
Identity correlation, especially if used only as a recommender for potential matches.
-
Role mining, suggesting roles that have to be reviewed by human.
-
Outlier detection, e.g. warning of potential privilege accumulation
Bad use of AI:
Use of AI for approval and certification is dangerous. There is a reason that this task was delegated to human. Using machine for such decisions often just a security theater.
Why would you use midPoint? Can you perhaps use something else instead?
It may seem strange to ask this question so far into the book. If you made it this far, you are probably persuaded about midPoint qualities. However, you will often be asked why have you chosen midPoint instead of something else. Identity management and governance market is quite over-crowded, with many products trying to do roughly the same thing. There is always a competing product. For almost every function that midPoint has, there is some other product that does that particular function better. However, there is no single system that does everything midPoint does, and it does everything better, cheaper and faster. Every product has advantages and disadvantages, every product has strengths and weaknesses.
MidPoint is an open source platform, developed by a company focused on technology. This seems the right way to do thing for us. However, vast majority of midPoint competition are commercial closed source products, backed by strong sales and marketing organizations. It is easy to make midPoint look weak, given the right framing and information cherry-picking. Many sales-driven corporations are very good at that. Therefore there is a benefit in knowing how midPoint fits in the "market" to be able to defend your position.
MidPoint is unified, compact, pre-integrated IGA platform. This means that midPoint has all the functionality that a common organization need to manage and govern identity data, or at least midPoint has an ambition to deliver such functionality. Not all the IDM/IGA products are designed like this. Many products are in fact a loosely-integrated bunch of several components.
Use of compact, pre-integrated system such as midPoint has numerous advantages, both for end users as well as engineers and system administrators. Compact, pre-integrated solution avoids the need to integrate the solution from several components, which is usually very demanding task. Solution composed of several products often lead to integration nightmares, policy duplication, data inconsistencies, upgrade problems and constant need for maintenance of integration paths. Therefore, we strongly recommend a solution, which has a unified IGA platform at its core, covering all crucial IGA functionalities. A platform such as midPoint.
Of course, there is a downside of unified, pre-integrated solution, provided by a single vendor. It can often lead to a vendor lock-in situation. Vendor lock-in is a situation where only a single vendor can improve your solution, only a single vendor can provide services for you, or the vendor has to approve or certify any services provided to you. It is very difficult to escape from such situation, as you have probably already heavily invested into the solution, making replacement very costly. This turns you from a customer to a hostage. Avoid vendor lock-in at all cost. Does that mean how have to avoid midPoint at all cost? Definitely not. MidPoint is different from most of its competition: midPoint is an open source platform. Anyone can provide midPoint-related services, and Evolveum has no power to do anything about it. Yes, Evolveum maintains a partner network, there are partner levels, marketing channels and all that usual commercial stuff. However, those are more-or-less just recommendations. We recommend that you engage one of Evolveum partners, companies that demonstrated ability to deliver midPoint-based solutions. However, if you choose to employ your local open source enthusiast to work on your midPoint deployment there is nothing to stop you - as long as an appropriate levels of professionally and expertise are maintained. There is no warranty to void, because in fact, there are no warranties in the software world anyway. There are no contracts to break, as the support contracts do not mandate exclusivity. There are no copyrights to violate, as all midPoint source code is out there, as is all the documentation. You are free to choose who will take care of your midPoint deployment. We will be happy if you choose Evolveum or one of its partners, but the ultimate choice is yours.
Every system has its boundaries. Identity governance and administration (IGA) systems are very powerful, they reach quite deep in many other systems, they permeate information infrastructures, they are at the center of everything. However, there are things that the IGA system cannot do, or would not do. This section summarizes where are the boundaries of IGA platform.
Privileged identity management (PIM) also known as privileged account management (PAM) deal with management of privileged accounts, accounts that have privileges far above the privileges of common user. These are usually shared system administration accounts in operating systems, databases and legacy applications.
PIM is sometimes considered to be part of IDM or IGA, sometimes it is considered to be separate. Formally, this is quite a gray zone. However, it does not really matter where it formally belongs. The important aspect is what PIM does, and what it should do.
Overall, we recommend not to use PIM system unless absolutely necessary. Many PIM systems are using agents that provide protection and auditing capability beyond native capabilities of protected operating system or application. The agent provides fine-grained control over privileged operations in the protected system. While such approach may seem attractive, the presence of an agent is a significant operational burden, complicating system updates, upgrades and general maintenance.
|
Note
|
Privileged account management (PAM) should not be confused with pluggable authentication modules (PAM), used by UNIX/Linux systems to carry out user authentication. These two systems just share the same acronym by coincidence, otherwise they have nothing in common. |
We rather recommend utilizing native capabilities of operating systems whenever possible.
For example, for UNIX/Linux system, we recommend avoiding use of root account entirely, disabling access to such account.
Rather than using privileged accounts directly, we recommend to use privilege escalation tools, such as sudo mechanism in modern UNIX/Linux systems.
MidPoint can be used to manage access to the privilege escalation mechanism, for example by controlling membership in UNIX/Linux groups.
MidPoint can also make sure that there is at least one active user with system administration privileges at all times.
All modern operating systems and applications have capability to control administration privileges in a user-centric and fine-grained manner.
Regular identity connectors could be used to manage access control policies of privileged accounts.
Legacy systems that do not have such capabilities pose a security risk on their own, therefore effort to upgrade or decommission them should be prioritized.
One of the common problems that often motivates PIM deployments is use of shared privileged accounts (such as root) for routine system administration.
However, this is a bad practice.
It is very dangerous, difficult to manage and almost impossible to use securely.
Avoid this practice.
It should be perfectly possible to use dedicated, personalized administrator accounts in current information systems.
Therefore, unless your IT is still in 1980s, you should be able to avoid use of shared accounts for routine administration, and keep them only for emergency situations.
If necessary, we recommend use of dedicated password vault application to store passwords to emergency privileged accounts. Such password vault could theoretically be integrated with midPoint sometime in the future, to change passwords of emergency accounts after use. However, assuming the number of emergency situations is relatively low, manual process may still be feasible, and even desirable. In case that the number of emergency situation is not low, then perhaps there is much more serious problem to address than automated management of privileged accounts.
Identity governance and administration (IGA) platform, such as midPoint, is only one part of a complete identity and access management (IAM) solution. Primary responsibility of IGA platform is management and governance of identity data and policies. However, policies are toothless unless they are enforced, and data are useless if they cannot be accessed. Other IAM components are needed to form a complete solution, most notably access management components and identity data stores. Such components provide functions that are not provided by IGA platform.
Quite naturally, components with the IAM solution need to cooperate. IGA platform is used to set the policies, that have to be reflected in identity data stores and enforced by access management systems. There is a lot of integration surface between components of IAM solution.
IGA platform deals mostly with the state of identity data, taking into account changes of the state. However, IGA platform does not deal with behavior of users. For example, a common requirement for IGA platform is to disable accounts that are not used in a long time. In theory, IGA platform can provide this function, provided that timestamp of last user login is recorded in the identity data, usually originating from a single sign-on system. However, such solution is far from being ideal. The account could be used even if user does not log in into the system in a very long time, for example using capability to execute scheduled tasks or using authentication that is processed by single sign-on system (e.g. SSH keys). The root of the problem is that analysis of user behavior is needed to reliably identify account that are not used. This is a responsibility of systems that mediate user activity, such as access management systems.
MidPoint includes some identity analytics functionality, and the ambition is to expand the functionality in the future. The identity analytics functionality of any IGA platform is designed to satisfy the needs of identity management and governance. It includes reports and visualization aimed at role design, management of identities, entitlement curation and similar responsibilities. The IGA platform is supposed to be self-contain in this capacity, i.e. identity administrators should not need any other system to do their job.
However, the identity-related data managed by IGA platform may have value for activities outside the IAM domain. There may be valuable business information hidden in the data. Parts of IGA platform functionality could be used to find business insights in the data. However, that is not the purpose of IGA platform. Sophisticated business analytics is not in a scope of IGA platform functionality. That is a job for business intelligence systems.
We recommend synchronizing selected data from midPoint to appropriate business intelligence system. MidPoint is an excellent data synchronization tool. Native synchronization capabilities of midPoint may be used to synchronize at least some parts of the data into the business intelligence platform. However, it is likely that a more sophisticated approach may be needed to feed summary and derived data into the business intelligence platform, such as custom data pumps and ETL jobs.
For example, midPoint identity analytic functionality is designed to analyze usage and structure of roles, or point out roles without owners. Future functionality might be used to locate users with risky or unusual access rights. However, midPoint should not be used to compute average number of persons in an organizational units, or estimate typical fluctuation of organization unit managers. That is a responsibility of business intelligence system, even though such reports may be based on data provided by midPoint.
Identity governance and administration platforms are mostly concerned with "here and now". MidPoint repository is full of data that describe current situation, current state of identities. There is limited amount of historical data in midPoint, mostly for short-term to mid-term accountability and diagnostics purposes, such as audit log records. However, midPoint is not designed to be a data warehouse. MidPoint is designed to store data for a long time. Keeping audit log records for months or even a couple of years is usually perfectly fine. However, do not expect midPoint to deal with years or decades of data. MidPoint is not designed to be a data warehouse. Data warehousing require special mechanisms, such as summarization of data, using cost-efficient high-capacity slow-access data storage, data long-term integrity guarantees and so on. There is no point of re-implementing such functionality in midPoint, data warehousing systems do that already. If data archival or a long-term data storage is needed, the data need to be transferred into appropriate data warehousing system.
Information contained inside midPoint is a precious resource for information security practitioners. It is expected that the information security team members will be heavy users of midPoint. However, midPoint is not a replacement for Security Information and Event Management (SIEM) system. MidPoint mostly deals with the state of identity information. There is also a considerable dynamics in midPoint as well, dealing with events such as re-organizations, data changes, policy violations and so on. However, such events are limited to the identity domain only. Much broader scope of information is needed to support information security management.
MidPoint is a precious source of information for SIEM system. It is expected that SIEM systems will process audit trails recorded by midPoint, as well as a static identity information stored in midPoint repository. MidPoint RESTful API can be used to transfer identity state data to SIEM platform. Direct access to audit database table is usually used to transfer event information from midPoint to SIEM platform.
Following table provides summary and clarification of border cases, specifying functionality provided by IGA plarform vis-à-vis functionality of other systems.
| MidPoint functionality | Functionality of other systems |
|---|---|
Operational reporting for identity management and governance purposes. |
Business analytics containing identity data. |
Monitoring of IGA processes |
General-purpose business process management |
Short-term storage of identity-related data |
Long-term data storage and archival |
Handling of identity-related events |
Handling of information security events |
Analysis and monitoring of identity data |
User behavior monitoring and analysis |
This chapter is not complete. Maybe it will never be complete. Similarly to midPoint project, this chapter is developed in an iterative and incremental fashion.
INVOLVE BUSINESS PEOPLE!
Business vs technology: both have to adapt/align.
-
Devel, testing, production environments; migrating configuration (cannot be completely automatized); devops, gitops, etc.