How to choose an Identity Manager (IDM)?

IDM features to ask about

The list is sorted in groups that are not ordered by importance. I will point out an essential group that I consider very important for each item.

Supplier

This is a critical choice for success. This is not an IDM feature, yet I think it belongs here. Choose the implementation team, not the product. A quality team can make similar music with different IDM products, the reverse is not true. How to do it? Have them design a solution to your needs. Let them show you references. Have the vendor justify to you on your environment how IDM will specifically help you. A demonstration of product features is absolutely not enough to select the right vendor!

What to decide:

1. Do I want a turnkey vendor, or will we implement the solution ourselves?
2. Do I want a supplier who is also the manufacturer (vendor) of the IDM product? If the supplier does not develop the product, only resells it, they may not be as flexible and knowledgeable about the details as the manufacturer.
3. Do I want a Czech product or a foreign one? Yes, there are also IDMs developed in the Czech Republic (we are one of the manufacturers). Czech IDMs usually have more support, for example, local HR systems such as Vema or Helios Orange/Green.
4. How many references does the supplier have? Call some of them. How many accounts do they manage?

Features, features, features

Everyone focuses on features, they are easy to compare. The amount of features seems to be essential. More is better. For me, not anymore.

In the past, IDMs were huge implementation tools (modules, libraries, connectors) for a team of programmers to customize for a given organization. For the return on such a large implementation to be meaningful, the organization had to be large. A lot of features make it harder to use, more expensive to implement and upgrade. Today’s trend is different.

IDMs are moving many functions away from programmers and into GUIs for admins. So that even the admin can do as many functions as possible himself, for example, easily connect a managed system. IDMs are simpler, more intuitive, easier to use and faster to deploy. Prefer less features that are easy to understand and use.

Who is the target group of IDM?

This is a key decision. Who will work most with IDM?

1. Users – typically they need to request and approve accesses quickly. The web GUI should be easy to understand and features as few as possible.
2. IT administrators – they will connect the system and set up account synchronization. The web interface should have lots of features, include wizards and be easy to use.
3. Or IDM will be background infrastructure software that syncs, integrates many systems. It will handle many transformations. The target then tends to be a team of programmers – implementers who do extensive customization.

Previously, IDMs were generic and very complex integration tools, hence the previous point 3. They could accomplish everything, but were complex and slow to use. Modern IDMs try to go the way of “standard features” that can be used by the administrator alone without implementers. Now IDMs are more specialized for identities, but they address more types of identities, see below.

Account groups addressed

There are 3 basic groups of user accounts – employees, suppliers and customers. Different types of IDM processes are applied to each account group – HR to employees, guarantor process to suppliers, etc.

Account groups:

1. Employees – Identity is usually created by the start of a contract term that is loaded into IDM from HR.
2. Externals – customers, contractors, students, etc. They access systems using VPNs, often using certificates. The IDM web interface can be used to create identities.
3. Technical and service accounts – for example, administrator or application accounts. These accounts usually may not be extinguished even after the account owner leaves. They cannot be subject to normal employee personnel processes. They have their own process agenda. IDM can also handle the password handover agenda.
4. Privileged accounts (PIM) – for example, an administrator in Windows.

Most IDMs are customized for employee accounts only. Modern IDMs have specialized features for PIM as well, such as temporarily adding a password for a technical account in the database.

Objects addressed in IDMs:

1. Accounts in systems,
2. Roles, role catalog – representation of a group of rights in a managed application or IDM,
3. Organizational structure
   1. Organization components
   2. Functional positions
4. Employment Relationships (ERR) – determined by the contractual relationship of the employee or contractor.
5. Assets – e.g. certificates, software licenses, key fobs, building cards, etc.
6. Groups, computer representation in a domain, etc.

IDM has historically worked with 1-3.

As part of the assignment, answer what accounts and other objects make sense for you to manage. Integrating and automating even with IDM costs some investment. It probably doesn’t make sense to automate a process that is rarely applied to a minimal account. Such a process can probably be done more cheaply by an administrator.

Nice and fast web GUI

This is an absolutely crucial point today. There are huge differences in the friendliness and speed of GUIs in IDMs.

Earlier IDMs looked like complex spreadsheets. The screens contained a lot of information, dials that took a long time to load. Times have changed. Users don’t want to read help pages anymore, they don’t want to wait for the display. Users want to complete their task quickly and move on – for example, reset a password or submit/approve an access request. That’s why modern IDM needs to be easy to understand. The user prefers less information, but user-friendly and damn fast. Web GUI responses need to be immediate, unless waiting for a response from a managed application (for example, password reset in Active Directory).

I recommend testing the quality and speed of the web UI. Take enough time to click through. Test frequent activities. If you wait for a redraw, it’s wrong. Choose another IDMko, users won’t like it.

Processes

A process is represented in the IDM by a workflow, as well as various synchronizations and user and system inputs. For simplicity, let’s think of a process as a sequence of events over an identity.

There are several basic types of processes:

1. HR processes:
   • employee onboarding and identity creation, job creation,
   • change of organizational assignment within a job,
     change of descriptive attributes (telephone, address, etc.),
   • exemption from the registration number (maternity/parental),
     termination of employment, loss of identity,
   • exemption from registration (maternity/parental leave),
   • termination of employment, termination of identity,
2. Manual user interventions in the web GUI – access requests, VPN, certificate and request approval, manual account creation by the administrator, etc.
3. Automatic synchronization between systems – accounts, roles, groups, organizational structure, but also any attribute.

The mapping and subsequent implementation of HR processes can be a significant item in the budget of an IDM project. Using the supplied standard processes can save a lot in implementation. Ask for standard HR processes and approval requests. Look at process diagrams to see if they at least roughly match your idea. Chances are good that you can use a process already included in the IDM and will not need to develop a customized one.

API frontend-backend

A sensible application interface is important for further expansion of IDM solutions. If there is a good and documented API (e.g. in the form of a REST API), then not only other systems can be connected to the IDM using it. Different portal applications will take data from the IDM, or perhaps different “tiles” to be integrated into the corporate intranet, etc. The advantage and actually the consequence of the presence of a well-designed API is that anyone can be an implementer of applications using identity manager data – internal IT, other vendors…
If you don’t plan to extend IDM, then you don’t need to give the API such weight in your decision making. Of course, you never know if it won’t suddenly be needed in a year or two.

Benefits of RESTful API:

• fast and flexible,
• widely used in current applications,
• one API supports easy centralization of communication and auditing,
• there are tools for clear documentation (e.g. swagger),
• facilitates integration with other applications.

License – OpenSource or CloseSource?

An opensource license offers the client more – freedom. However, the license has nothing to do with the quality and suitability of the IDM. It is not true that opensource IDMs are generally better or worse.

Find out:

1. How limited is the licence? The usual limitations – number of instances, connectors, users, time period, operations processed, modules, customers, etc.
2. What services does the vendor offer – maintenance, SLAs, development services, product roadmap, etc.

I don’t want to go into detail about the possibilities. Licensing is a complex subject, consult a lawyer.

Performance and speed

By speed, I mean the response to a user request in the web GUI. I have discussed this in the section on web GUI.

Performance – how many identities the IDM processes per unit time when synchronizing between systems. This parameter makes sense to address if you already have thousands of some of the objects – accounts, roles, groups or timesheets, etc.

IDM typically performs many computationally intensive operations during synchronization, which take considerable time even on powerful HW. Example of operations IDM performs during synchronization – retrieve from end system, compare changes, execute changes, audit operations, run HR processes, data transformation, synchronize with other systems, run approval processes, run reports…

We have customers with millions of accounts or roles. It makes a big difference whether IDM processes a sync in 4 hours or 4 days.

For synchronization, ask for change (opposite of complete) synchronization options that are orders of magnitude faster. Change synchronization only considers objects that have changed since the last run, so it does not go through all objects. For a large number of objects (on the order of tens of thousands or more), change synchronization can run for minutes, while full synchronization will run for hours or days.

I recommend setting the performance metric to process 1 account max in 1 sec, but it depends on the end system. If the SAP web service is equivalent to 1 s, then IDM will logically just add time.

Upgradability

Upgradability is a subtle parameter that can tell you a lot about the modernity of an application. How often are new versions of IDM released? Only 1 per year? That may be low, as upgrades can be very time consuming, expensive. When acquiring an IDM, ask how much work it costs to do an IDM upgrade. Upgrading the product itself should be a matter of minutes. Customized/customized parts can extend an IDM upgrade to weeks.

Quality code

Checking the quality of the code makes sense if you want to implement and modify the IDM with your own team of developers. How to know the quality of the code?

By many parameters:

• interface quality,
• the documentation of the code,
• code covered by tests,
• readability and understandability,
• maintainability and extensibility,
• input control, error conditions, integrity, etc. etc.

Documentation

Quality documentation is a sign of a quality program. It will be needed for the future development of the environment. IDM is usually a long term solution that grows with the organization.

Quality documentation is an expensive thing. Product datasheets and how-to procedures in GUIs are not enough. You need to have a description of how your solution’s user management processes work internally. How systems are integrated, what data is passed where, how it is transformed. IDM tends to be integrated, customized. The documentation needs to be from an administrator’s perspective, but also from a developer’s perspective.

Roles (RBAC)

IDM sets rights based on role assignment, i.e. RBAC – Role-Based Access Control. This is the basic functional mechanism of IDM. If I get a role, it typically means that I have gained access to the system or some specific permission on the system (for example, inclusion in an MS Active Directory group).

Role types:

• Application role – I have a role, I have access to an application or a specific right in an application.
• IDM access roles – I have a role, I have some higher authority to work in Identity Manager. For example, I can approve someone’s rights.
• Business roles – group the above. For example, the “secretary” role has roles for the Attendance system and Helpdesk.
• According to the type of assignment:
  Automatic – for example, based on organization affiliation, time or based on an attribute near the identity.
• Manually by an administrator or based on a request and approval by an authorized person (supervisor, business owner of the role, etc.).

Support for managed systems?

Any system that is available over the network and whose identity structure is known can be connected to the IDM. The connector is a small software tool on the IDM side that allows data exchange with the connected system using its native API. Thus, the connector adapts to the connected system, not the other way around. Which is a huge advantage of IDM in ease of connection.

Some IDMs specialize in one world – for example, Microsoft IDM integrates AD, Office 365 and SharePoint. However, outside of their world (think other applications, such as SAP), these IDMs may no longer have the supplied connectors.

Ask your vendor. The list of supported systems tends to be very extensive. If you don’t have a local system, it will be supported.

There are basic connectors:

1. Scripted SQL Connector – for connecting SQL databases, multiple tables.
2. LDAP connector
3. Powershell Connector – to connect AD domain, Exchange and O365 administration.
4. WS Web Service
5. Flat File – to retrieve data from a file.
6. Database Table Connector – to connect a simple SQL table.
7. CSV Directory

What to look out for with the offered connector?

• Whether the connector supports your version of the managed system.
• What features/operations the connector supports. For example, whether it supports account lockout, password change, or change synchronization.
• What objects in the end system it supports. For example, Active Directory connectors often do not support group management.
• Licensing restrictions, because the cost of the connector may not be low.

Conclusion

Choose an IDM vendor, not just a product. Don’t focus so much on features, but on solving your challenges. IDMs are systems for years of use. I recommend not to rush the selection, look at references and choose the path of smaller simple projects with clear and precise specifications. Have a PoC – a small test project.