02-midpoint-overview.adoc

MidPoint Overview

chapter-include.adoc

Chaos was the law of nature; Order was the dream of man.

— Henry Adams

MidPoint is an open source identity governance and administration (IGA) platform. It is a very rich and sophisticated system that provides many advanced features. MidPoint is maintained by Evolveum – a company dedicated to open source development. All midPoint core developers work for Evolveum. However, there are also partners and other engineers that are contributing to midPoint development.

One of the main differences between midPoint and other IGA systems is that midPoint is designed and implemented with one primary goal in mind: practicality. This goal goes deep into the very foundations of midPoint. To be more concrete, we understand practicality as:

• Things that are simple or frequently used should be easy to configure. Propagation of password changes, enable/disable of user, account synchronization – these should be as easy as possible. As simple as flicking a switch, or setting few configuration properties.

• Things that are more complex or used less frequently may be a bit harder. Such as editing XML, YAML or JSON file, or writing few lines of Groovy script.

• Things that are very complex or very unusual should be still possible. However, these might not be easy. It may require longer scripts, or implementing some Java classes. In extreme case, it may even require forking and modifying the source code. However, it must be possible to do almost anything.

Simply speaking, midPoint is following the Pareto principle: 20% effort brings 80% benefits. There are many mechanisms that support this approach. Some are based in midPoint design, some originate from midPoint development practices and some are even supported by the Evolveum business model.

Simple solutions which do not deviate from the usual requirements must be easy to implement. Good identity and access management programs start simple, solving common problems. The start should be relatively easy, granting benefits early in the project. The project then proceeds in iterations, each iteration improving upon the previous one. Each iteration is bringing tangible results. As the requirements get more complex, the implementation effort may grow. The project may eventually reach a point where the effort outweighs the benefits. This is the right place to stop, maybe return to the project later.

This is known as iterative and incremental process. It is proven to be efficient and practical approach many times over. MidPoint is designed for this process, right from its very beginning. It is at the core of midPoint development philosophy.

MidPoint is an open source system. Therefore, there is no license cost that would offset the initial costs. Even small projects are feasible with midPoint. You can start prototype or proof-of-concept projects today. There is no need for any paperwork. Just download midPoint and start. Right now. You can see for yourself what midPoint can do.

How MidPoint Works

MidPoint does what any identity management system is supposed to do: it manages identities. The very basic functionality of midPoint is the synchronization of identity data that are stored in various applications, databases, directory servers and cloud data stores. We call all these systems identity resources, or resources for short. MidPoint is using connectors to reach the identity resources. MidPoint can propagate a change that happened in one identity resource to other identity resources. E.g. an employee record appears in the HR system, it is picked up by midPoint, processed, transformed and then new Active Directory and CRM accounts are created. This is the process that we call synchronization. It is at the core of everything else that midPoint does.

MidPoint has a rich graphical user interface (GUI) that can be used to manage the identities. Changes made by system administrators are automatically propagated to all affected identity resources. E.g. security officer disables a user by clicking on btn:[Disable] button in midPoint user interface. Then MidPoint makes sure that all accounts that belong to the user are immediately disabled.

This is the essence of midPoint operation. It sounds simple, because this description is extremely simplified. The reality is much more complicated. Most of the important things happen inside midPoint before the changes are applied to target resources. For each change that midPoint detects it needs to evaluate:

• Roles: MidPoint computes where the user should have access. This is usually given by the roles that the user has. The role structure is often quite rich and dynamic. There may be role hierarchies, parameters, expressions and policies to consider.

• Organizational structure: Users usually belong to organizational units, projects, teams or groups. Some of them may give additional privileges to the user, or they may apply policies.

• Status and life cycle: Accounts can be created, enabled, disabled, archived or deleted. There are many situations in the lifecycle that need to be considered. E.g. we may want to create a disabled account one week before a new employee starts his work, enable the account on his first day, disable the account on his last day and delete it three months after he leaves.

• Attributes and identifiers: Simple synchronization scenarios assume that attributes and values should be the same in all the synchronized systems. That is a nice theory, but it almost never works like that in real world. In reality there are incompatible attribute names, data formats and conventions to take into consideration. Attribute names need to be translated, values need to be transformed, data types need to be converted. This is different for each system, and even for each instance of each system. Small algorithms in form of scripting expressions are often needed to properly transform the values.

• Credential management: Password changes need to be propagated to the target systems. Sometimes we want to synchronize password with all systems, sometimes we want just a subset of systems. Password policies need to be evaluated, password history needs to be checked, password may need to be encoded, encrypted and/or hashed before storage.

• Policy rules: Policies are evaluated, each rule applied to current situation. The rules may prohibit illegal situations, such as dangerous combination of roles. Policy rules may mark the object for later inspection by administrator. The rules may do almost anything to make sure the system is compliant.

• Authorizations: Some users are more powerful than others. There are midPoint administrators with very powerful privileges, there are delegated administrators that can manage only a small part of the data, and there are end users with access to self-service only. MidPoint has a very flexible authorization mechanism, allowing thousands shades of privileges to be applied to arbitrary subset of data and operations. The authorizations need to be evaluated for every operation that midPoint makes.

• Consistency: The account in the target application might have changed since midPoint has updated it. The current change may no longer be applicable to the current state of the account. The change that midPoint wants to make may conflict with the native change, the change may be partially applied already, the account may have attribute values that it should not have or the account may not exist at all. MidPoint has to detect such situations and react accordingly, e.g. by re-creating a deleted account before applying the changes.

• Approvals: MidPoint determines if any of the changes need to be approved before they are applied. If that is the case, then midPoint drives the request through an approval process. There may be multiple stages of approval, approver groups, optional approvers, the request can be escalated if approvers do not take action in time and so on. Approval process may be quite complicated, the actual steps are computed individually for each request, based on approval policies.

• Notifications: MidPoint can notify users when important events happen. E.g. it notifies the user that he can access a new account, or it notifies the administrator if something goes wrong.

• Audit: MidPoint records all the changes into an audit trail. This can be used by security officers or specialized analytic engines later to investigate past situations and changes. Audit trails provides accountability.

This is a lot of things to process, evaluate and execute. Some of these steps are quite complex. Indeed, there are many sophisticated algorithms implemented in midPoint. There are algorithms that evaluate role structures, organizational structures, temporal constraints, policy rules, password policies and so on. MidPoint does all that for you. The only thing that is needed is to configure them properly.

However, midPoint does even more than that. MidPoint does not only manage identities, it can also manage any object that is anyhow related to identity management. MidPoint can manage roles, role catalogs, organizational structures, groups, projects, teams, services, devices and almost anything else you can imagine.

MidPoint is also an identity governance system. The job of identity management features is to make sure that the policies are consistently applied through the organization. The governance features assist with the maintenance and evolution of those policies. MidPoint implements access certification process. This is a recurring process that asks managers to confirm that the users still need the privileges that they have previously received. MidPoint contains mechanism to sort roles into hierarchies and categories. That is necessary to maintain order during role engineering and maintenance of role definitions. MidPoint has mechanisms for selective enforcement of role which comes very useful during migrations and when new system is connected to midPoint. MidPoint has support for policy lifecycle, general policy rules and so on. Even more work in that direction is planned in future midPoint versions. We fully understand that it is not enough to simply apply the policies. Policies are living things and they need to evolve.

Last, but certainly not least, midPoint provides visibility. Identity data often look like a huge maze, a labyrinth or users, roles, organizational units, entitlements and policies. It is too easy to get lost there. However, there are treasures in that labyrinth. There are patterns and structures hidden in that huge pile of data. Roles and policies buried there, as well as risks and dangerous anomalies lurking behind the corners. MidPoint provides identity analytic capabilities to uncover them. There are powerful reporting and simulation mechanisms. Recent midPoint versions introduced role mining, a capability to find role patterns in the data. MidPoint gives identity professionals capability to see inside identity data.

Case Study

This book is about practical identity management. Therefore, we will get very close to a practice by demonstrating midPoint features using a case study. This is a case study of a fictional company ExAmPLE, Inc. The name stands for "Exemplary Amplified Placeholder Enterprise". ExAmPLE is a mid-sized financial company. Its operation heavily relies on information technologies, therefore there is a diverse set of applications and information systems ranging from legacy applications to cloud services. As ExAmPLE has few thousand employees and there is a good potential for growth, the management has decided to start an identity and access management program. The first step of the program is deployment of midPoint as the identity governance and administration platform.

Eric is an IT engineer at ExAmPLE, Inc. He has taken the responsibility to install and configure midPoint. Eric spins up a new container with midPoint in it. Couple of minutes later, midPoint instance starts up. Eric logs in to the midPoint user interface.

MidPoint instance is almost empty after fresh installation. It contains only a couple of essential objects. Luckily, Eric is a smart engineer. He has already read through this book, and he knows exactly what he needs to do.

First thing to do is to populate midPoint with employee data. The primary source of ExAmPLE employee data is an HR system. The HR system is quite big and not entirely flexible piece of software. It is not easy to connect to that system directly. Fortunately, it is quite easy to get a text export of the employee data in comma-separated (CSV) format. Eric plans to use this file to get employee data to midPoint.

Connectors and Resources

MidPoint communicates with all the source and target systems by the means of connectors. Connectors are relatively small Java components that are plugged into midPoint. There is usually one connector for each type of the connected system. There are connectors for LDAP servers, Active Directory, databases, cloud applications, UNIX operating systems and so on. The responsibility of a connector is to translate protocols. E.g. LDAP connector translates midPoint search commands to LDAP search requests. Database connector translates the requests to SQL language. Cloud connectors translate midPoint search commands to HTTPS requests for their respective cloud APIs. The UNIX connector creates an SSH session and translate midPoint create command to the invocation of Linux useradd binary. And so on. Each connector talks using its own communication protocol on one side. On the other side, the connectors translate the information to a common format that is understood by midPoint.

There is no distinction between source and target system when it comes to the connector. The same connectors are used for source and target systems. The difference is only in midPoint configuration.

The connectors are distributed as Java binaries (JAR files). To deploy them to midPoint you just need to place them in the correct directory. MidPoint automatically discovers and examines the connectors during start-up. A handful of frequently-used connectors is even bundled right into midPoint distribution. These connectors do not need to be deployed, they are automatically available.

Connector of a specific type works for all the systems that communicate by the protocol supported by connector. E.g. LDAP connector works for all the LDAP-compliant servers. Connector is a very generic piece of code. It does not know the hostname, port or passwords that are needed to establish a connection to a particular server. The configuration that specify connection parameters for individual server is stored in special configuration object called resource. The term resource in midPoint terminology means identity resource, any system which contains identity data and is connected to a midPoint instance.

Therefore, Eric the Engineer needs to define a new resource in midPoint in order to get ExAmPLE employees into midPoint. This resource represents the CSV file exported from the HR system. MidPoint distribution contains CSV file connector already, therefore there is no need to deploy the connector binary package. All that Eric has to do is to create a new resource definition. There are (at least) two ways to do it. Firstly, there is a resource configuration wizard in midPoint user interface. Eric can use the wizard to configure a new resource from scratch. However, Eric is quite an experienced professional, and he is also a little bit impatient. Therefore, he decides to use the other approach: start from an example. There are examples of various resource definitions in the midPoint distribution package, and even more examples are available on-line. Eric quickly locates an XML file that contains a complete example of a CSV resource. He edits the file to change the filesystem path to his CSV file and adjusts the names of the columns to match the format of his file. The very minimal resource configuration specifies just the resource name, connector and connector configuration. The XML file that Eric creates looks approximately like this (simplified for clarity):

resource-csv-hr-bare.xml

<resource oid="03c3ceea-78e2-11e6-954d-dfdfa9ace0cf">
    <name>HR System</name>
    <connectorRef type="ConnectorType"> ...</connectorRef>
    <connectorConfiguration>
        <configurationProperties>
            <filePath>/opt/midpoint/var/resources/hr.csv</filePath>
            <fieldDelimiter>,</fieldDelimiter>
            <uniqueAttribute>empno</uniqueAttribute>
        </configurationProperties>
     </connectorConfiguration>
</resource>

Tip	If you are a hands-on type of engineer you probably want to follow what Eric is doing in your own midPoint instance. All the files that Eric is using are provided in a form of ready-to-use samples. Please see Additional Information chapter at the end of this book for the details.

Then Eric navigates to menu:Configuration[] section of midPoint user interface and imports the XML file into midPoint using menu:Import object[] tool. Import operation creates new resource definition in midPoint. Eric now navigates to menu:Resources[All resources] in menu:Administration[] section of the midPoint user interface. The new CSV resource is there. When Eric clicks on the resource name a resource details screen appears.

Eric can click on btn:[Test connection] button to test connection to the resource. As this is a local CSV file, there is no real connection. The test checks that the filesystem path is correct, that the file exists and that it can be opened. The connector reads the CSV file header to discover the structure of the data in the CSV file, and presents the information to midPoint. This is stored in midPoint as resource schema, which describes structure of accounts in this resource. The resource is now prepared for use.

There is not much that Eric can do with the resource yet. We need to explain a couple of essential midPoint concepts before moving forward with our case study.

User and Accounts

The concept of user is perhaps the most important concept in the entire identity management field. The term user represents physical person: an employee, support engineer, temporary worker, student, teacher, customer, etc. On the other hand, the term account refers to the data structure that allows the user to access applications. This may be an account in the operating system, LDAP entry, row in the database table and so on. Typically, one user has many accounts – usually one account for each resource.

The data that represent users are stored in midPoint, while the data that represent accounts are stored "on the resource side". Which means that accounts are stored in the connected applications, databases, directories and operating systems. Accounts are not stored in midPoint. Under normal circumstances, MidPoint keeps just account identifiers and some meta-data about the accounts. All other account attributes are retrieved when needed. MidPoint is using the connectors to fetch account data.

Note	Terminology We will strictly distinguish the terms user and account in this book. Such a strong distinction is also made in the midPoint user interface and documentation. It is very useful to get used to this terminology.

Accounts are linked to users that own the accounts. MidPoint knows which account belongs to which user. MidPoint can list all the accounts for any user, it can synchronize the data, it can disable all the accounts of a particular user and so on. This user-account link is almost always automatically established and maintained by midPoint.

MidPoint comes with a built-in data model (schema) for users. It contains properties that are frequently used to describe users such as full name, e-mail address and telephone number. There is a reasonable set of properties that should be a good starting point for most deployments. Of course, as most midPoint objects, the user schema can be extended with custom properties if needed.

However, there is no built-in data model for accounts. Such data model would not be possible. Every resource may support different account attributes. Account attributes may have different names, different types and the values may have different meaning. MidPoint is designed to handle those differences.

Account schema may significantly differ from resource to resource. Yet midPoint must be able to synchronize all the accounts from any kind of resource imaginable. In this case the user schema works as a unifying data model. The schema of each account is mapped to the user schema.

Schema for resource accounts is dynamically discovered when midPoint connects to the resource for the first time. MidPoint interprets the schema and automatically adapts to it. E.g. when midPoint displays information about an account, the user interface fields are dynamically generated from the discovered schema. MidPoint does that all by itself. No extra configuration and no coding is necessary. Except for one thing. We need to tell midPoint which type of account is the right one.

Many systems support variety of object types: accounts, groups, roles, organizational units. We call such types object classes in midPoint. Similarly to account attributes, object classes vary from resource to resource. Therefore, we need to specify which object class is the right one to use for accounts. Resource definition has schemaHandling section which is designed for this kind of specifications:

resource-csv-hr-minimal.xml

<resource oid="03c3ceea-78e2-11e6-954d-dfdfa9ace0cf">
    <name>HR System</name>
    <connectorRef type="ConnectorType"> ...</connectorRef>
    <connectorConfiguration>
        <configurationProperties>
            <filePath>/opt/midpoint/var/resources/hr.csv</filePath>
            <fieldDelimiter>,</fieldDelimiter>
            <uniqueAttribute>empno</uniqueAttribute>
        </configurationProperties>
     </connectorConfiguration>

    <schemaHandling>
        <objectType>
            <displayName>HR Record</displayName>
            <delineation>
                <objectClass>AccountObjectClass</objectClass>
            </delineation>
        </objectType>
    </schemaHandling>

</resource>

This is how we tell midPoint that resource supports object type (using objectType clause) that is interesting for us. This object type should be labeled as HR Record in midPoint user interface. The connector will use AccountObjectClass object class when dealing with this type of accounts. MidPoint now knows how to access our HR records in a form of accounts in HR System resource.

Getting back to our ExAmPLE story, Eric has an HR resource configured. Now he can see the "accounts" that the users have in the HR system. Eric opens the resource detail page in the midPoint GUI and navigates to menu:Accounts[] panel. There is not much to see yet. We would like to see all the HR records here. However, reading all the accounts may be quite a demanding task, therefore midPoint does not do it automatically. Eric has to click on btn:[Reload] button to initiate the process for the first time. The list of accounts appears:

All that can be seen in this list are just employee numbers, because employee number is set as the primary identifier for the HR system. Click on the employee number displays more details about the respective "account". However, these data are not real accounts in this particular case. These are lines in the CSV file exported from the HR database. However, they describe some aspects of user’s identity, therefore midPoint interprets them as accounts. For midPoint, "account" is a generic term used to describe any resource-side data structure that represents the user.

Initial Import

The user is a central concept for any identity management system, and midPoint is no exception. MidPoint needs reliable information about users to work correctly. The HR system is usually a relatively good source of user information. Eric needs to get that information from the HR system into midPoint. He has already set up a resource that connects to the CSV file exported from the HR system. However, the resource does not do anything interesting by default. It has to be configured to pull the information from the HR file into midPoint. What Eric needs is a set of mappings. Mapping is a mechanism for synchronization of attribute values between user and accounts. In this case, Eric needs inbound mappings to import the data. Inbound mappings synchronize the value in the direction from the resource into midPoint. Eric can open the resource definition in the configuration wizard in GUI, and he can add the mappings there. However, Eric likes to know how things work. He looks at the configuration samples again, and he adds the mappings in the XML form. Inbound mapping looks like this:

resource-csv-hr.xml

    <attribute>
        <ref>firstname</ref>
        <inbound>
            <target>
                <path>givenName</path>
            </target>
        </inbound>
   </attribute>

This is a mapping that maps the account (HR) attribute firstname to user (midPoint) property givenName. This tells midPoint to always update a value of user’s given name when the mapped HR attribute changes. Eric adds similar mappings for all the attributes in the HR export file. Eric also needs to add synchronization section to the resource definition. The synchronization section instructs midPoint to create a new user for each new account that midPoint discovers. This is exactly what Eric wants: create a user for each HR account. Eric then re-imports the modified XML file into midPoint.

Tip	For the curious and impatient readers, complete definition of HR resource is stored in resource-csv-hr.xml file in book samples. Please see Additional Information chapter for the details.

MidPoint is now ready to synchronize the attributes. MidPoint is ready, however it does not do anything yet. We still need a task to pull all the data from the HR system. Eric navigates to the page that shows the list of HR accounts. There is a btn:[Tasks] button which can be used to manage tasks that manage the accounts. Eric clicks on that button and creates a new import task by menu:Create task[] option in the drop-down menu. He creates an Import task. All he needs to do is fill out task name (e.g. HR Import) in the task wizard, everything else is pre-set to reasonable default values. When Eric clicks on btn:[Save & Run] button, the task is started, and it runs for a couple of seconds. After the task is done Eric can look at users in midPoint by navigating menu:Users[All users] in main menu:

Eric can see details about the user by clicking on the username:

This page shows all the details about the user that midPoint knows about.

The details are sorted into several sections. We are going to explain all of that later in this book. For now, we only care about first two sections. The menu:Basic[] section shows user properties as midPoint knows them. These properties are stored in midPoint repository. MidPoint has quite a rich data model that can be used out-of-the-box, but the GUI only shows those properties that are actually used. The "name", given name and family name were imported from the HR resource and that’s what the page shows.

Let’s have a look at the second tab now, clicking on menu:Projections[] in the details menu:

The menu:Projections[] panel shows user’s accounts. Currently, there is only one account. It is the HR record that was used to import the data. Account details are displayed by clicking on account identifier:

The data that are displayed here are really fresh. Account details were retrieved from the resource at the very moment that the account was displayed. This is the difference between user data and account data: user data are kept in midPoint repository, while account data are retrieved from the resource as needed.

The user and the account are linked. MidPoint remembers that this user originated from this specific HR account. If the HR account is modified, then the change is synchronized and applied to the user data. The mappings are not just for the import. They can work continually and keep the account and user data synchronized all the time.

Assignments and Projections

The concepts of an account is all about the reality: it shows the data that are there at this very moment. It shows what is there. However, identity management is all about policies. Policies, by definition, specify what should be there. Policies specify what is right. However, as every citizen knows all too well, the things that are and the things that should be do not always match perfectly. We are no idealists. Therefore, we have designed midPoint from the day one to acknowledge that there may be a difference between reality and policy. It is a prime responsibility of midPoint to manage that difference - and align policy and reality as much as possible in the long run.

This kind of thinking is easy to see in midPoint user interface. There is menu:Projections[] panel in the user details page. It shows the accounts that the user has right now. It shows the real state in which the accounts are. It shows the reality. Then there is menu:Assignments[] panel. This panel shows the policy. It shows what accounts, roles, organizations, or services are assigned to the user. It shows what user should have.

We need a new resource to demonstrate how the assignments work. Therefore, let Eric connect a new resource to midPoint. This time it will be new, clean and empty LDAP server. Eric once again locates the proper example, modifies the configuration and imports it to midPoint. In a while, there is a new LDAP resource. Eric wants to synchronize all the users to the LDAP server. To do that, Eric has to define mappings once again. They will be outbound mappings this time, as Eric wants to propagate data out of midPoint into the (LDAP) resource. We will cover the details of mapping configuration later, let’s just see the results now. We have two resources now:

Tip	For the curious, LDAP resource configuration is located in resource-ldap.xml in samples directory.

How do we create an account on that LDAP resource? The right way to do this is to let midPoint know that a user should have an account on that resource. In midPoint terminology we say, that we are assigning the resource to the user. Eric needs to edit a user (navigate to user list menu:Users[All users], select a user), navigate to resource assignments panel by click on the menu:Assignments[Resource] in the details menu, and use unassuming btn:[New] button on the bottom of empty list to add an assignment for the LDAP resource:

After the click on btn:[Save] button, a lot of things happen. MidPoint recomputes what the user should have and what the user has. MidPoint detects that the user should have an LDAP account now (because there is a new assignment for it). However, no such account exists yet. Therefore, midPoint creates the account.

When Eric opens the user details again, and navigates to the menu:Projections[] panel he can see that there are two accounts now:

There is an HR account that was used to create the user in the first place. Then there is an LDAP account that was created as a reaction to a new assignment.

There is reality and there is policy. There are accounts and there are assignments. Ideally these two things should match perfectly. MidPoint will try really hard to make them match. However, there may be exceptions. Careful reader surely noticed that there is HR account, but there is no assignment for that account. Despite that, midPoint has not deleted the HR account. That is because the HR system is what we call a "pure source" system. MidPoint does not write to the HR, it only reads from it. Writes to the CSV export file would be overwritten by the next export anyway, therefore there is no point in writing there. For that reason, the HR resource has an exception specified in its configuration: it allows the HR account to exist even if there is no assignment for it. We can keep the HR account linked to the user by using this method. We can see the data that were used to create the user. This improves overall visibility, and it is a great help for diagnostics of configuration issues.

Roles

It would be a daunting task if Eric had to assign every individual account for every individual resource to every user. Typical identity management deployment has thousands of users and dozens of resources. Such deployment would be very difficult to manage using direct resource assignments only.

There is a better way, of course. We can use roles. The concept of role-based access control (RBAC) is a well-established practice. Indeed, the roles are the bread-and-butter of identity management. The basic idea of RBAC is to group privileges into roles. Then the roles are assigned to the users instead of privileges. Let’s create a Webmaster role. Then put all the privileges that a webmaster should have into that role. Let’s assign the role to every user that works as a webmaster. All of them will get the same privileges. This simplifies the privilege management. If there are two webmasters, there is no need to think about the individual privileges that a webmaster should have. Just assign the role, the role has everything that is needed for a webmaster to do his job. It is also easy to change webmasters: unassign role from one user, assign it to another user. It is also easy to adjust privileges if you add a new web server. Just add the privilege for accessing new server into the Webmaster role. All webmasters will get that privilege.

That’s the theory. How does it work for Eric? First of all, let’s add a handful of new resources – to get some material for the roles to work on. Now we have four resources: HR, LDAP, CRM and Portal. That’s a good start. Let’s do some role engineering now.

Many organizations have one role that almost every user has. It is often Employee or Staff role. This role gives access to all the systems that an employee should have access to: Windows domain login, e-mail, employee portal – things like that. The ExAmPLE company is no exception. In this case the basic role should create accounts in two systems:

• LDAP server: many applications are connected to LDAP and use it for authentication. We want every ExAmPLE employee to have account there.

• Portal: this is enterprise intranet portal with lots of small services essential for every employee.

It is simple to create such role in midPoint user interface. Eric navigates to menu:Roles[New role]. Role wizard starts, prompts for a role type. We cannot create neither application nor business role, as we do not have basic structure for that yet. Therefore, Eric selects the last option. He fills in the name of the new role (Employee). Then he navigates to the menu:Inducements[All] panel. This is where the role definition takes place. Inducements are almost the same as assignments. However, inducements do not give access to the role itself. Inducements give access to the users that have this role. So they are kind of indirect assignments. Eric clicks on btn:[New] button, and adds inducements for LDAP resource into the role, by selecting the menu:Resource[] tab and selecting LDAP resource. He repeats the process for Portal resource as well.

Eric clicks the btn:[Save] button, and the new role is created. Now it is ready to be assigned to the users. Eric goes on and assigns Employee role to user Bob by editing the user and adding a role assignment:

MidPoint automatically creates all the accounts given by the role after the modification is saved:

There is the HR account that was used to create the Bob user record in the first place. Then there are the two accounts that were created because Bob has the Employee role: portal account and LDAP account.

This operation works in both directions: if Eric unassigns the Employee role, the accounts given by the role will be deleted. Eric can create any number of roles like this: roles for sales agents with CRM access, roles for sales managers with higher CRM privileges, roles for assistants and clerks, roles for everybody. MidPoint is designed to handle large number of roles. Each role can have its own combination of resources and entitlements. MidPoint seamlessly merges the privileges given by all the roles a user has. E.g. if two roles give CRM access to the user, only one CRM account will be created. If one of these roles is unassigned, then CRM account remains there. The account is not deleted yet because it is given by the other role. Only when the last CRM role is removed, that’s the point where the account gets deleted. MidPoint takes care of all that logic.

Note

Archetype Strictly speaking, role is not an ideal tool to use for Employee access. Employee is usually more than a role, it is a type of user. We would probably want to assign employees their own icon, we want Employee type to appear in quick access menus, and so on. MidPoint has a very special mechanism to do that: archetypes. However, you do not need to forget everything that was said about roles so far. Archetypes work exactly the same as roles do, with assignments, inducements, and all of that. This is how we do it in midPoint: one generic mechanism, reused for many things.

Of course, there is much more midPoint roles can do:

• Roles can assign accounts to groups, grant the privileges and manage account entitlements.

• Roles can mandate specific account attribute values, e.g. clearance levels, compartments, etc.

• Roles may contain custom logic (expressions, scripts).

• Roles may be hierarchical: there may be roles within roles.

• Roles may be assigned for a specified time.

• Roles may be conditional and parametric.

• …​ and much much more.

Roles are really the essence of identity management. We will be dealing with assignments, roles and role-like objects in almost all the parts of this book.

There Is Much More

Eric the Engineer has done a few basic steps to configure midPoint as an identity management system for his company. However, this is still a very basic configuration. It is only a beginning. Careful readers have already noticed a lot of things that need to be done. E.g. employee full name is not automatically generated. Employee numbers are used as identifiers. We would like to have something that is more user-friendly instead. We need to automatically assign the Employee role instead of doing that manually. And so on. There are still a lot of things to improve. Fortunately, all of that is very easy to do with midPoint, once you know where to look. We will be dealing with all these things in the rest of this book. New functionality will be administered to the ExAmPLE solution in small doses in each chapter – together with a proper explanation of midPoint principles. MidPoint is a very flexible and comprehensive platform, and there are still a lot of things to learn.

What MidPoint Is Not

Now you probably have some idea what midPoint is. However, it is also very important to understand what midPoint is not. Identity and Access Management (IAM) field is a combination of many technologies, and it may be quite confusing sometimes. That is perhaps the reason why the midPoint team occasionally gets questions about midPoint functionality that simply do not make much sense.

First of all, midPoint is not an authentication server. MidPoint is not designed to validate your username and password. Yes, midPoint maintains data about users (including passwords). However, the data model that midPoint maintains is quite complex. It is not meant to be exposed to applications directly. That would not be very efficient.

If you want midPoint to manage users, but you also want your applications to have a centralized authentication service there is a solution: publish the data to the LDAP server. Connect LDAP server to midPoint as a resource, and let midPoint populate and maintain the LDAP sever data. The application will not talk to midPoint directly. They will talk to the LDAP server. This is better for everybody: LDAP is a standard protocol, well-supported in many applications. LDAP servers are also extremely fast and scalable. Therefore, use the combination of midPoint and an LDAP server of your choice. That’s what people usually do and it works perfectly.

Of course, we said that LDAP is not authentication server either. That’s right, it is not. However, LDAP can still work for simple authentication scenarios. If you need more than that, connect a proper authentication server to LDAP. That is what most authentication servers expect anyway.

As midPoint is not an authentication server it obviously is not a single sign-on (SSO) server either. If you want SSO, you will need a dedicated SSO server. There are plenty of SSO servers to choose from in both the closed-source and open-source worlds. You will also need a scalable directory system (LDAP) to store the data for the SSO server. MidPoint will be pleased to manage that LDAP server for you.

One of the things that seems to be shrouded in a lot of confusion is authorization. To get the record straight from the beginning: midPoint is not an authorization server. It is not a policy decision point (PDP), and it definitely is not a policy enforcement point (PEP). You cannot rip authorization out of your application and just "use midPoint for that". That does not work.

You can think of midPoint as a policy administration point (PAP). MidPoint has a lot of sophisticated authorization-related logic inside its core. However, that logic is not designed to answer questions such as "Is subject S authorized to execute operation O on object X?". MidPoint logic is different. MidPoint is not concerned with making authorization decisions. It is concerned about managing the authorization policies. MidPoint sets up the authorization policies in target applications. The applications evaluate these policies themselves. This is a much more efficient and more reliable method. Unlike authentication, the authorization decisions are done all the time. Authorization is evaluated at least once per every request. If the application makes these decision internally, then there is no need to a round-trip to the authorization server. Performance is significantly increased. Also, there is no single point of failure. MidPoint failure will not interrupt authorization flow, because the application has all the data inside. One less component to cause a failure. Yet, the policies are centrally managed by midPoint. When a policy changes, midPoint updates all the affected applications. You get all the benefits without the usual drawbacks.

MidPoint does what it is supposed to do: it manages identities, entitlements, organizational structures and policies. MidPoint does not do things that are not necessary. It does not do the things that other technologies already do well. MidPoint does not reinvent the wheel. There is no need for this. MidPoint is not the wheel. MidPoint sits above all the wheels. MidPoint is the chauffeur.