Identity Provisioning and Synchronization

At its core, MidPoint has a powerful connector-based IDM engine. A connector is a simple piece of code that moves identity data (e.g., an account) from a source system to a target system. MidPoint connectors are based on the Connectors for Identity Management (ConnId) framework that is used by many open source and commercial IDM software products. This is handy because connectors are interoperable across any ConnId-based IDM system, including MidPoint.

Connectors are relatively simple blocks of code that implement a standard interface. There is almost no IDM logic in the connector. The synchronization business logic is located inside MidPoint, reducing bloat in the connectors themselves. The same logic is reused for all connectors.

MidPoint saves the account-to-person link information in its database and continuously keeps data synchronized. Once a data mapping is configured, it is reused for provisioning, synchronization, data import tasks, and other IDM functions. This unifies IDM policy and simplifies maintenance.

MidPoint can also map data to populate account attributes. A mapping can pass values unchanged or can transform values with a script (Groovy, JavaScript, or Python). Conditional mapping provides flexibility for propagating data based on context, such as a role or association with an organizational unit. Administrators can also define manual processes to supplement data with information provided by business people.

Synchronization can be configured to work in “both directions”. For example, MidPoint can push information about a person from a Human Resources system to an LDAP server. The LDAP server itself may be authoritative for other information, like the person’s password. MidPoint can aggregate the data and synchronize it to all required systems.

MidPoint can synchronize data about any object type that is accessible by a connector, not just user attributes. For example, MidPoint can read data from a relational database table and create an LDAP subtree or a nested group, use the location of an entry in the LDAP tree to provision data in a relational database table, or automatically create an LDAP role entry based on group.

Connectors can also be configured to send notifications to alert people that their account was provisioned. They can also perform system administration tasks, such as the creation of home directories, mailboxes, or password policies. The possibilities are almost limitless.

Role Management

Roles are used by most IDM platforms and are central to how MidPoint organizes privileges. Role Based Access Control (RBAC) is a strategy used by many organizations to authorize access to resources. However, RBAC has a dark side: if roles are used to reference each unique access requirement, the number of roles can grow exponentially. In fact, some organizations have more roles than people! This is known as “role explosion”. MidPoint uses several strategies to reduce the impact of role explosion, such as enabling dynamic expressions inside roles to make roles conditional, so one role is included in another role only if a specific condition is satisfied.

MidPoint roles may be based on specific user data, or a parameter of the role itself. For example, roles such as Sales Assistant, Engineering Assistant, and Logistics Assistant can be simplified with one generic Assistant role, where the organizational unit (sales, engineering, or logistics) is just a parameter to that role.

In MidPoint, role evaluation can be applied to the roles themselves, enabling the creation of meta-roles. For example, it is common for roles to be divided into several types, such as application roles, business roles, or technical roles. Roles may share common characteristics such as an approval process or lifecycle policy. Instead of duplicating common attributes, business roles may be assigned a meta-role to define common characteristics across all business roles.

Organizational Structure

Traditional IDM is primarily concerned with synchronizing changed information about people, but many important changes aren’t about the person, rather their place in the organization. Organizational structure such as regions, divisions, departments, work groups, projects, sub-projects, ad hoc teams, faculties, classes, realms, tenants, and domains all affect which systems a person should be able to access. Many parallel organizational structures can be modeled in MidPoint. For example, there may be one big tree that represents a functional organizational structure, and a semi-flat structure of projects, ad hoc groups, and so on. A person may belong to any number of organizational units in any organizational structure. Mathematically speaking: if your structure can be expressed as an acyclic oriented graph, it can be modeled in MidPoint.

Membership in an organizational structure may include privileges to access certain resources. Therefore, organizational units can be used to control access in the same way as roles. However, the leaders of a business unit may have different access than ordinary members. In MidPoint, the organizational unit manager is a specific relation a user can have to the organizational unit and is decoupled from organizational unit membership itself. This enables a person to be a manager of an organizational unit of which they are not a member.

Organizational structure can be synchronized in the same way as a person’s accounts. MidPoint mappings can be used to transform organizational structure and maintain it in the form of LDAP groups, organizational units (OUs), entitlements, roles, or almost any form.

Approval Processes

MidPoint can assign roles and organizational units automatically, for example, based on job codes. This is an efficient and scalable approach, but is typically only feasible for a small subset of roles. Administrators can manually assign other roles and organizational units, but this is not scalable. Therefore, most IDM deployments use a process-based approach where the person requests required roles. The request is then routed through an approval process where individual approvers can make decisions about the request.

Frequently, the first stage of the approval process is performed by a person’s manager. Further stages may require approval from a business owner, security officer, resource owner, or project manager. In most IDM platforms, the approval process is driven by an internal workflow engine, which is customized using a workflow language such as Business Process Model and Notation (BPMN). This is a very flexible approach, however, approval workflows tend to get extremely complicated and can become difficult to maintain.

Rather than complex custom workflows, MidPoint supports “policy-based” approval processes driven by declarative approval policies. The approval process for each role request is dynamically computed based on associated policies. An approval policy can be defined globally, individually for each role, or for a group of roles (using the meta-role mechanism). A policy may specify approval stages that are mandatory, optional or conditional. Each stage may have different approvers or approver groups. MidPoint also supports approval escalation, delegation, and auditing. Policy-based approval means no programming is needed to set up an approval process, enabling very complex policies to be defined and maintained efficiently.

Even though MidPoint offers strategies to reduce role explosion, there may still be tens or hundreds of roles in the system. To simplify the process of assigning roles, MidPoint offers a role catalog and shopping-cart style request process for people to browse categories, select the appropriate roles, and request approval.

Midpoint Delegated Application Security Model

MidPoint’s internal authorization mechanism controls access to MidPoint objects such as users, roles, organizational units and resources. Fine-grain authorization policies can be specified down to the level of individual object properties. The authorization mechanism is aware of the organizational structure, enabling delegation of identity administration within an organizational unit to its respective managers, and the delegation of roles to its owner. The same mechanisms used to access target systems can be used to obtain access to MidPoint itself. Therefore, access to data in MidPoint can be requested, approved, and audited.

MidPoint also enables a person to specify a “deputy” who can temporarily obtain their authorizations and privileges. This can be useful when a person is traveling or on leave. The deputy can access the work items (approval decisions) of the delegating user. The deputy also gains access to entitlements in target systems, for example temporary assignment to the same LDAP groups. Privileges are automatically revoked when the operational time has concluded. Deputy functionality is meant to provide continuity of business processes both inside MidPoint and in target systems.

Auditing

MidPoint can maintain an audit trail for changes to data about people, roles, organizational structure, and configuration. A complete description of changes and any useful metadata is available for any MidPoint object. A feature called “time machine” enables the restoration of any past state. Audit trails are recorded in a database table and can be used to integrate MidPoint with security information and event management (SIEM) or data warehouse systems.

Access Certification

Role request and approval processes tend to result in a person accumulating many roles over time. However, because removal of roles no-longer-needed is often overlooked, it’s important for organizations to regularly perform access certification campaigns (i.e., “recertification” or “attestation”). For example, once per year, managers may need to decide if the roles assigned to subordinate employees are still needed. The MidPoint web interface enables managers to efficiently make these decisions. Once certification decisions have been submitted, any superfluous roles are automatically marked for removal and unassigned.

Removal of a non-sensitive role is not an urgent matter. However, certain situations might require faster action, for example if an employee is moved to a different organizational unit with a different manager. The new manager assumes responsibility for the employee’s roles and should execute an ad hoc recertification process for that specific user.

Policy Rules

Businesses must abide by certain rules and regulations. Executives are tasked with determining which rules are appropriate. Information technology professionals are responsible for implementing those rules in systems. An example is segregation of duties (SoD). For instance, it may be inadvisable for a person to both write and sign checks. Another example—at an investment banking firm, you can’t advise companies about mergers and acquisitions and trade securities.

Midpoint policies express rules governing organizational structures and roles, such as “a project must have at most one manager” or “a role must have at least one owner”. Policy rules can express policy-based approvals, which may also govern role lifecycles. The totality of policies determines the governance of the organization.

A single policy rule has two parts: a constraint and an action. A constraint defines a situation or event where the rule applies, such as “A is assigned to a user” or “A is assigned together with B”. If the constraint is triggered, then an action takes place. Actions may be as simple as “prohibit such an operation”. But actions can also be complex, for example, removing all conflicting assignments or driving a request through an approval process or re-certification.

Policy rules can be combined to form more complex business logic, such as “prohibit assignment of A and B at the same time”. MidPoint enables administrators to combine policy rules with meta-roles and approval processes. An example might be: “if any two roles from this set of roles are assigned to the same person, then drive the request through an approval by a security officer”. Such combinations are used to implement advanced features like ad hoc recertification and role lifecycle management.

User Interface (UI)

The MidPoint UI is designed to automatically adapt to custom inputs. For example, an LDAP server may have a custom LDAP attribute called “foo”. When MidPoint connects to that LDAP server for the first time, it retrieves its schema, including the custom “foo” attribute. The resource schema is stored in MidPoint and automatically used for all data processing. It is also immediately reflected in the web user interface, automatically rendering an input field for that attribute. No programming or customization is needed to use this functionality. The web interface also automatically adapts to authorizations. Only those pages to which the user has access are displayed, and all inaccessible forms and input fields are hidden or displayed as read-only.

Of course, some customization may be required. MidPoint offers configuration options to specify how certain parts of the web interface behave, for example, to hide widgets or unused features.

Services and Integration

All three interfaces offer roughly equivalent functionality. The Java libraries are used by the MidPoint UI, therefore, those interfaces can be used to build a custom UI or to integrate MidPoint with other systems for management, advanced tooling, or various other purposes.

Other MidPoint Features

MidPoint offers additional features not included in this overview, including flexible reporting capabilities, self-registration and self-service password reset procedures, self-healing capabilities, and virtual identities (or “personas”). In addition, the IDM system is an ideal place to track and protect identity data, and development is ongoing to add features to enable better protection of data—a key requirement for compliance with the European Union General Data Protection Regulation (GDPR ).

Get Started with MidPoint

Visit the Evolveum MidPoint wiki to learn how to get started: https://wiki.evolveum.com/display/midPoint/Introduction .

Syncope Architecture

A bird’s-eye view of the architecture is shown in Figure 9-1.

Admin UI is the web-based console for configuring and administering active deployments, with full support for delegated administration.

End User UI is the web-based application for self-registration, self-service, and password reset.

CLI is the command-line application for interacting with Apache Syncope from scripts, particularly useful for system administrators.

Core is the central component, providing all services offered by Apache Syncope.

The REST interface can be accessed either via the Java client library or using plain HTTPS calls.

Syncope Provisioning

Like MidPoint, the Provisioning layer for Syncope relies on ConnId. ConnId is the continuation of The Identity Connectors Framework (Sun ICF) project, which used to be part of the Sun Microsystem IDM product and has since been released as an open source project. This makes the connectors layer particularly reliable because most connectors have already been implemented in the framework and widely tested.

The ConnId project features contributors from several companies and meets the requirements for a modern, active open source project, including an Apache Maven driven build, artifacts, and mailing lists (see Figure 9-2). Additional connectors, such as for SOAP, CSV, PowerShell, and Active Directory, are also provided.

Syncope Extensions

Syncope Installation

Visit the Apache Syncope documentation to learn how to get a local instance up and running: http://syncope.apache.org/docs/getting-started.html .

Wren:IDM Quick Start

To begin using Wren:IDM, do the following:

1. 1.

   Visit https://wrenscurity.org to get the Wren:IDM package, either by downloading a binary package or building from the latest sources.

    
2. 2.

   Make sure you have Java 8+ installed. Both OpenJDK and Oracle JDK work well. Extract the package to a folder and navigate there using your terminal.

    
3. 3.

   Run the startup script startup.sh (UNIX/Linux) or startup.bat (MS Windows).

    
4. 4.

   Open http://localhost:8080/admin in your web browser, log in with the default credentials openidm-admin:openidm-admin, and explore the administration interface (see Figure 9-3).

    

System Overview

Working with these objects is pretty straightforward. For example, when you patch a managed object like a user, it is updated in the repository and configured actions take place. When you patch a system object like an account, it is updated in the integrated system. Audit trails will appear in the system in both cases. The main system components are shown in Figure 9-4.

Wren:IDM Pre-Defined Types

There are a number of pre-defined types in Wren:IDM.

Relationships

These are managed object attributes used to connect one managed object to another. You can defined them to synchronize data unidirectionally or bidirectionally, one-to-one, one-to-many, or many-to-many. For example, consider an organizational chart in which one person reports to another. Such a relationship is frequently represented as a bidirectional relationship in IDM between two users—the “manager” and his “direct reports”. Another example are the roles mentioned previously—each of a user’s roles is represented as a predefined “roles” relationship in each user. As is the case for all other IDM objects and attributes, relationships can be retrieved through the API or shown in administration GUI, as shown in Figure 9-5.

Wren:IDM Processes

Beyond the data and entitlements that Wren:IDM manages, there are also several processes Wren:IDM uses to maintain the data. These concepts include the following.

Example: Make Your Own Self-Service GUI

You can use the Wren:IDM default user-facing self-service website. However, there might be situations when a custom solution is preferable, either for self-service or for administrative tasks performed by, for example, the help desk staff. The simplicity of implementing such a solution is one of the strengths of the platform. The following steps provide an overview of how to create a custom self-service website.

Example: Consent Governance

Role and assignment resolution mechanisms also provide a way for various IAG rules to be enforced in real time.

For example, let’s imagine a company “H.Q. Pennyworth & Co,” which has brokers who work with clients. Imagine that the firm has a business rule that requires brokers to make contact information readily available to those clients. To enforce this rule while complying with local regulations, a Pennyworth broker must consent to sharing his personal contact information. If a broker has not yet consented, you want to restrict either his roles or resource grants. In such a case, having the broker role is a necessary—but not sufficient—requirement for having broker access.

As suggested, the restriction can be made on two different levels and the difference is conceptual (see Figure 9-6):

• Restriction at the role resolution level—An employee without consent won’t effectively get the broker role even if it is assigned to them.

• Restriction at the assignment resolution level—An employee without consent can effectively get the broker role, but they still won’t be eligible to get the assigned resources.

Example: Connector Configuration with Object Mapping Transformations

Let’s say we want to set up the mapping suggested in Figure 9-7.

When Is Wren:IDM Suitable?

In small to medium organizations that have only a single location —or multiple locations where identity information is owned by a single location—other IDM products that make a lot of assumptions about corporate structure may be faster to implement.

In medium to large organizations, where there are branch offices and/or organizational units that need to have autonomous control over their identity information, Wren:IDM is an excellent fit.

Effectively, Wren:IDM is so flexible that you could end up spending a lot of time on integration when something out-of-the-box fits your model. But if your organization isn’t cookie-cutter, and you have some requirements that take you a little outside of the other solutions, then Wren:IDM is a better solution, even if it might take a bit more time to integrate, because it’s built to handle the customization. The time spent integrating pays off in flexibility and maintainability of the implementation.

Rolling Out Wren:IDM to Production

Wren:IDM can run with any JDBC-connected database, but has been tested with PostgreSQL, MySQL, Oracle, and Microsoft SQL. In addition, for local development and testing purposes, it also ships with an embedded copy of OrientDB. In general, Wren:IDM shares dependencies common to any lightweight JEE application. It runs both on Oracle JDK and OpenJDK.

A single, commodity-hardware machine with 4GB of RAM would be sufficient to run the whole solution, including a PostgreSQL database server on a Linux operating system. The requirements grow with the number and frequency of scheduled tasks and complexity of the particular actions. The system can be also operated in a cluster. While high availability is usually not a requirement for IDMs, cluster-based deployment can help by distribute reconciliation tasks across several nodes. In addition, if direct access to target systems from the IDM is not possible or desirable (e.g., the target system is local, but IDM is running on Amazon EC2), connector servers can be used to provide an interface from the IDM to the target system.

The limiting factor in most deployments is the I/O throughput of the target system; specifically, how quickly such a system can query records and return them. If you’re using existing connectors, take note of options that can reduce the amount of data that a connector will need to request from the remote system (e.g., limit base DNs, filter out objectclasses that are not of interest). If you’re developing custom connectors for an IDM project, it is best to optimize the connector to query the target system for as few records as possible.

There are several approaches to deploying and testing Wren:IDM. A good implementer can leverage software engineering best practices such as using SCM, test-driven development, continuous integration, and continuous delivery. Wren:IDM works best in such a process.

Architecture

Casa is a Java EE web application that runs inside the Gluu Server’s chroot container, although it’s distributed as a separate package. Casa interacts directly with Gluu’s underlying LDAP server and file system, and uses the oxd-java library to leverage Gluu’s OpenID Connect Provider (OP) and UMA Authorization Server (AS) functionalities. Casa is built using frameworks such as Weld, ZK, and RestEasy.

Casa’s core functionality—self-service 2FA management—is enabled via a Gluu Server custom authentication script written in Jython. The script enables a person to specify their preferences for 2FA—whether to prompt for every authentication, to remember a certain location, or to remember the browser.

2FA Credential Management

2FA can significantly increase account security. However, security is only as strong as its weakest link. If you have a strong authentication mechanism, but you can use email to recover from a lost credential, your security is degraded. Control of email is an even weaker credential than a password! If a human operator can reset a strong credential, people are extremely susceptible to social engineering. Don’t hack the crypto—hack the people! Account recovery is the Achilles heel of 2FA, as an authentication mechanism is only as strong as the weakest recovery process.

As there are no widely accepted Internet standards for account recovery and strong authentication, it can be helpful to review and mimic how industry giants like Google support these important security processes. With one billion user accounts, Google has lots of data to determine how to roll out secure and usable 2FA.

Google supports several types of authentication: SMS, OTP, FIDO tokens, and several others. With billions of accounts, strong security can’t come at the expense of usability—that’s why Google offers a self-service portal where people can enroll, delete, and manage their own strong credentials.

Gluu Casa provides an open source solution that organizations can use to offer a similar user-facing, self-service 2FA experience. In the Casa dashboard, people can enroll and manage their strong authentication credentials to secure their accounts.

Out-of-the-box, Casa supports the same credentials as Google: FIDO, OTP, SMS, and mobile push (using Super Gluu). This combination of 2FA options makes strong security available to anyone with a mobile phone. The self-service dashboard empowers people to enroll multiple strong credentials to thoroughly secure their account.

Net-net, the value of the transaction should drive security enforcement, and in the Casa administration web interface, system administrators can manage which 2FA mechanisms are enabled and supported by the system.

Consent Management

Federated identity enables people to leverage an existing account in an identity provider (IDP) to create and maintain a passwordless account in an external service provider application (SP). For example, when you “Sign in with Google” to an unaffiliated third-party website, Google may send along personal information about you that will be used to create a local profile for you (sans password). In these situations, before allowing you to proceed, the IDP will prompt you to “consent” to the release of personal information (in OAuth jargon, this is the authorization). In addition, Google may prompt you to authorize the third-party website to perform actions on your behalf, for example to access your contacts or update your calendar.

As the user’s window into the authentication system, Casa provides a UI for reviewing and revoking previously made consent decisions. For example, if you sign in to Dropbox using your Gluu IDP account, then decide you no longer want Dropbox to be able to control your calendar, you can revoke your consent decision in Casa. The third-party website could (and likely would) retain a copy of any personal data previously shared, but would no longer have authorization to perform actions on your behalf—it would need to re-prompt you for consent if you attempt to access the service again using your external IDP account.

Social Login Account Management

Creating and remembering passwords for each service is not only a terrible user experience, but people tend to re-use passwords in many systems, which can quickly lead to account security issues. Not all systems are secured equally! Spreading your password across the Internet like the seeds of an ailanthus tree certainly increases your risk of compromise.

Casa offers people the ability to enroll and remove social login accounts available to the Gluu Server as a means of authentication. For example, you could create your account by signing in with Google, then enroll a Twitter, GitHub, and Facebook account to provide multiple options for accessing your account. This way, even if you get locked out of Google, you can still access your account.

Developer Portal

In order to support federated authentication and authorization, application developers need client credentials from the IAM system (i.e., client-id and client_secret). Client credentials enable an application to identify itself to the IAM system. Depending on the scopes granted, client credentials can be used for different purposes. Casa provides an interface for people to request and manage client credentials in the IAM system, enabling a more convenient developer experience and greater transparency and accountability for system administrators.

Getting Started

Gluu Casa can be deployed via Linux packages. Visit the documentation to learn how to get a local instance up and running: http://gluu.org/docs/casa .