How our identity manager was born

Introduction

In order to develop an identity service solution, we need to understand the components. Even if we want to meet our needs based on Commercial or Free Open Source Software (FOSS), having a common understanding of the subject will help us to select the proper solutions.

A comprehensive identity service solution includes the following:

• Identity management
• Access management
• Access governance
• Identity Store

Identity management service keeps identity data consistent and synchronized across different identity stores. The main functions of identity management are:

• Provisioning/De-provisioning
• Workflow automation (Approvals & Workflows)
• Self-service password reset
• Identity synchronization

For example, when a person is hired by an organization, this may trigger a workflow where accounts are created in several systems, approvals may be needed, and equipment may be issued and when a person leaves the organization, accounts need to be removed or inactivated.

Access management service provides user authentication (how Users are let accessing a given system/application) and authorization (which capabilities each user owns on a given system/application). Access management solutions support the following functions:

• Authentication
• Single sign-on (SSO, Web SSO)
• Identity Brokering, Federation
• Access control (Role-Based, Rule-Based, Attribute-Based, …)
• Standard Authn, Authz protocols (like LDAP, SAML 2.0, XACML, SCIM, OAuth 2.0, UMA, OIDC)

Access governance is the process of decision-making and the process by which decisions are implemented. Access governance main functions include:

• Role catalog, lifecycle
• Access certifications
• Segregation of duties
• Auditing and Reporting

Identity Stores are the places where identity-related information (like identities, attributes, and credentials) is stored.

Requirements

Less likely we find a single solution that covers all the above functionality. So we should determine our requirements and select proper solutions. At the time of writing this document, there is some free and commercial software, deployed to control access to our company assets. They don’t have enough capabilities to manage all identity data through its lifecycle. Besides, the identities are stored in several data stores on-premises and on the cloud, and identity provisioning and de-provisioning (especially in onboarding and offboarding) take several days. So we need to provide a technical solution to improve the identity management process and decrease provisioning/de-provisioning time.

Challenges

One might suppose that a single identity store can solve all the identity needs inside an organization, but few drawbacks are just around the corner:

• many applications require a local user database
• changes in third party applications like HR and CRM are out of our control
• heterogeneity of systems makes this solution complex or in some cases impossible

In contrast, having different identity stores makes difficulties in the provisioning and de-provisioning process increases the number of orphaned users and makes it difficult to prevent privilege creeping. Besides, keeping identity data consistent and synchronized across different identity stores, is another point that should be considered.

The last but not least point is enforcing company access policies and deploying automated approval workflows in the provisioning/de-provisioning process.

Open-Source Solutions

In our solution, we should consider the concerns mentioned above and the current status of our company’s Infrastructure.

There are great open-source solutions like Apache Syncope, midPoint, Wren:IDM, and OpenIDM that can be used to manage the Identity lifecycle in an enterprise. But before using them we should pay attention to the following points:

• The main part of an IDM is identity connectors. Identity connectors enable provisioning software, to manage the identities that are maintained by a specific identity store. They provide a consistent layer between IDM and identity stores and expose a set of operations for the complete lifecycle of an identity. So, we should ensure that chosen solution supports all the identity stores that we want to manage in our company’s current and near-future infrastructure.
• Developing new connectors may be our future need. If so, the IDM technology stack is another point we should consider.
• Deploying an IDM is not as easy as it seems. Even well-documented IDMs may need well support to deploy in a complex, heterogeneous environment.

Our Solution

Considering all available solutions, and our requirements, we decided to develop our identity manager software to manage all identities at our company’s current and future infrastructure.
We inspired a lot from available great open-source solutions, especially Apache Syncope, and developed our solution. The below describes the architecture of our IDM.

We designed a multitenant software to segregate administration between our business ventures and serve them with one install of the application. At least there are three approaches to create multitenancy:

• Shared database with shared schema
• Shared database with isolated schema
• Isolated database with a shared app server

As the number of our tenants is limited, a shared database with an isolated schema was our preferred approach. Because it provides more secure data isolation compared with the first method and has less administration headache compared with the third one.

IDM Clients

Our application’s tenants have four groups of clients. Superusers who can configure the application and have privileged access to different parts of the application (except reports and audits information). Users, only have access to application self-service in order to reset their passwords on different identity stores. Requesters (HR in onboarding/offboarding and Team Leads in access changes), who make create/change/disable/delete user requests. Approvers (Team Leads and System Owners), who approve requests and determine users’ access while approving.

IDM Front-end, Back-end

In order to secure access to different parts of the application, role-based access control is used. Access to all forms and reports can be defined by the superuser. Every requester/approver can be limited to request/approve on specific identity-stores, user-access levels, and user groups.
To secure the authentication process, password complexity, password age, password history, two-factor authentication, and account lockout have been deployed.

Three types of approval workflows have been defined in our IDM:

• Create-user
• Change-user
• Disable/Delete-user

The first and third workflow is used during onboarding and offboarding, and the second one is used when a user’s access/role/position changes. Workflow engine manages workflows creation and running.

There is also a capability to delegate access to Adhoc requests (on some or all identity stores) to a user. The Adhoc request is a means of bypassing workflows and create/change/disable/delete users on identity stores, instantly. So, it should only be used in case of necessity. All requests (including Adhoc requests) are subjects of auditing and trigger an audit record in the audit table.

Superuser (or authorized user), can define scheduled tasks. Scheduled tasks are tasks that can be launched at pre-defined times or after specified time intervals.

The tasks manager is responsible for scheduling, queueing, and running tasks. Five types of scheduled tasks can be defined:

• Create Users Mappings: When IDM connects to an Identity store for the first time, we can run this task to create a mapping table between IDM internal users (list of personnel that we have imported to the IDM database) and Identity stores’ users automatically. It’s an amazing feature that helps us update the IDM information in several minutes, especially when there are thousands of users on identity stores. It has three levels of user mapping accuracy (High, Medium, Low). Lower levels result in more mapping hits while increasing the chance of mistakes.
• Sync Groups Information: Instead of defining all identity stores’ groups manually, on IDM, we can run this task and import several thousand groups automatically.
• Sync Users Information: Users are members of different groups and their membership changes over time. This task updates the IDM users access table with the last user access changes on identity stores.
• Reset Users Password: By scheduling this task, we can rotate users’ passwords periodically. This task helps us to implement a password change policy in our company. Besides, in the case of special security incidents, we can change users’ passwords on some or all identity stores in a short time.
• Delete Orphaned Users: If we decide to delete orphaned users on some or all identity stores we can schedule this task.

Scheduled tasks’ results store in the reports table.

Identity Provisioner (IdP)

Identity Provisioner (IdP) is the last part of our IDM architecture. At its bottom layer, there are drivers. Drivers help IdP connects to Identity stores and sends/receive Identity change requests/responses.
At the top layer, the Rest API layer provides an abstraction layer between IDM backend and IdP drivers. So, any changes in the drivers will not affect the upper layers.
In order to secure access to different parts of the IdP, role-based access control has been deployed. JWT access token is used to authenticate and authorize IdP connections. All sensitive data in-transit and at-rest are encrypted with strong cryptographic algorithms, a rate-limiting mechanism is used to prevent brute force attacks, and ECS-compatible logging has been deployed.

Our company has many Identity stores in different regions/zones, on the private and public cloud. In order to manage those identity stores, we have deployed IdP agents on different zones/regions and connected them to a central IDM server.