Note: This section describes the platform architecture for the Community edition (CE). The architecture for the Enterprise edition (EE) contains differences which enable improvements in scalability, performance and security. The architecture for the EE can be found in its corresponding documentation.

Background

Identity and Access management (IAM) platforms are an essential part of an organization's IT infrastructure. Over a decade ago, when OpenIAM released the first version of its IAM platform, these solutions were largely found in large enterprises. These organizations had and continue to have significant investments in these solutions as they were complex, expensive to deploy and to maintain (i.e. there was a high total cost of ownership).

Primary drivers for IAM in those days were related to automation and cost savings. Today, IAM deployments can be segregated into Workforce Identity and Customer IAM. The drivers for each are different. Workforce Identity solutions are often driven by a need to meet regulatory requirements. Customer IAM (CIAM) deployments are outward facing and focused on both improving security and the end-user experience while they consume services that are being delivered to them.

While these drivers have expanded the audience that is ready to consume IAM solutions, legacy IAM solutions do not offer the breadth of functionality that is needed. This new audience demands solutions that are:

• Sensitive to the total cost of ownership.
• Faster and easier deployments.
• Have a modern architecture which can integrate with a hybrid environment of on-premise and cloud solutions, on-shelf and custom applications.

To support this diverse audience, OpenIAM takes a significantly different approach in delivering an IAM platform. This document provides a high-level overview of the underlying architecture in OpenIAM to enable this goal.

One OpenIAM

OpenIAM, like many of the IAM vendors, has several functional components that make up its stack:

• Identity Governance
• Web Access Management
• Customer IAM
• Multi-factor Authentication.

Unlike other vendors, which see each product as a separate deployment, OpenIAM views its solution as a single unified platform where:

• Common services and infrastructure components unite the solution.
• Functionality, which is common across stack components such as authentication, user management, audit, etc. can be viewed as a shared service.
• Customers can enable business functionality as needed.

Logical Architecture

The diagram below provides a view of the OpenIAM solution architecture. OpenIAM uses an n-tier architecture and with each significant release, the micro-services architecture has become increasingly granular.

The architecture is organized into three distinct tiers:

• User Interface (UI) Layer
• Service Layer
• Infrastructure Layer

Referring to the diagram above:

• Blue boxes depict functionalities offered by OpenIAM.
• Gray boxes represent infrastructure components within the stack. These components are used consistently across the platform and come with a wrapper service layer for seamless integration into OpenIAM.

The heart of OpenIAM's functionality lies in the service layer, where the UI acts as its client. Detailed descriptions of each service within this layer are provided below.

Messaging

RabbitMQ plays a pivotal role in the OpenIAM architecture as the primary messaging engine. It fosters seamless communication among all services, thereby enabling the decoupling of these services—a foundational principle in microservices development.

For instance:

• When the provisioning service needs to ascertain a user's privileges, it dispatches this request to the authorization service via the message bus.
• Upon determining its required actions, the provisioning service can then dispatch relevant events to both the provisioning connectors and the audit service using the message queue. This communication among services happens asynchronously.

Key advantages of the message bus within OpenIAM include:

• Scalability: It supports the scalability of specific microservices.

• Deployment Flexibility: It allows for a flexible architecture, permitting services to shift across different hosts or subnets. As long as they remain connected through the messaging engine, smooth operation is ensured. This flexibility is especially beneficial for provisioning, given that target systems may be situated across diverse subnets.

• Enhanced Responsiveness: By facilitating asynchronous processing of operations, the system can respond more swiftly to demands.

Caching

Redis is used for caching. Redis functions as an in-memory data structure store, embodying a distributed key-value database with optional durability. Within the OpenIAM framework, Redis serves dual roles:

1. As a primary cache, it's instrumental in amplifying the performance of operations by caching objects in both the service and UI layers. This reduces the need for frequent backend repository accesses, ensuring faster and smoother operations.

2. Concurrently, Redis acts as a secondary cache in the persistence layer, streamlining access to the Relational Database Management System (RDBMS).

Given its multifaceted role, Redis stands as an indispensable component in the OpenIAM stack, underpinning operational efficiency and agility.

ElasticSearch

ElasticSearch is a distributed search and analytics engine. OpenIAM maintains a variety of information in Elasticsearch including a replica of user information and audit logs to enable full-text searching and analytics of the logs. These would be too expensive to run against an RDBMS in large deployments.

Workflow engine

OpenIAM uses Activiti as a Business Process Model and Notation (BPMN) compliant workflow engine. Workflows are used extensively in OpenIAM for a variety of tasks ranging from request-approval, object creation, terminations, position changes/transfers and access certification. Activiti enables the modeling of complex workflows which are potentially unique to each organization.

Groovy script manager

Similar to Activiti, which is used to extend OpenIAM using workflows, Groovy script is used to extend OpenIAM where scripting is appropriate. Functions such as scheduled tasks, attribute rules, pre and post processes and many more can be implemented programmatically using Groovy script. It can also be combined with the workflow engine to create an open framework where new business rules and processes can interact with both internal and external resources.

Scheduler

The IAM platform allows creating scheduled tasks. For instance, so common scheduled tasks are:

• Password expiration notifications.
• Detecting accounts that have been inactive and then changing their status to inactive.

OpenIAM includes a number of out-of-the-box scheduled tasks which can be customized using, for example, a Groovy script. The frequency of scheduled tasks is controlled through a Cron expression. The OpenIAM scheduler framework allows authorized users to see:

• Tasks which have run and their outcome.
• Currently running tasks and the ability to cancel them.

Device Manager

The device manager represents a first step towards a comprehensive Internet of Things (IoT) framework. The device manager enables the registration of devices such as phones, tablets, etc. with OpenIAM. The registration process allows the platform to control which devices can be registered and which can't.

Vault

Hashicorp Vault provides the ability to dynamically manage secrets and protect sensitive data. It's used in OpenIAM to manage sensitive cryptographic keys which are essential to the security of OpenIAM solution.

Flyway

Flyway is a database versioning and migration component. It's used in OpenIAM to simplify the management of the OpenIAM schema and control schema upgrades from one version to the next.

Shared Services

The shared services are used across the platform regardless of OpenIAM use case. These services internally make use of the infrastructure components described above. Examples of shared services include (this is a subset):

• Authentication
• Authorization
• User Management
• Encryption
• Configuration management
• Audit Logging.

Identity management services

Identity management (IdM) and governance requires integration with both source and target systems. To enable this, OpenIAM provides several services which include:

• Provisioning and deprovisioning along with corresponding Pre and Post Processors.
• Synchronization - provides functionality used to import/synchronize data from an authoritative source such as your company's HR system, e.i. Workday and SAP HR. Synchronization can also be used to load data from other systems using connectors or a CSV file.
• Reconciliation - uses the connectors to integrate with target systems and ensure that both the target and OpenIAM are synchronized. If they are not in sync, then rules can be defined to take appropriate action.
• Connectors - services allowing communication with business applications to support provisioning, deprovisioning, synchronization, and reconciliation processes. During provisioning or deprovisioning, the provisioning service will submit a message on a queue and the appropriate connector will pick up the request. The connector will perform the requested operation on a business application.
• Source Adapters - special type of connectors which allows external processes to submit a file (CSV/XML) for synchronization using either HTTP(s) or FTP(s). To the client submitting the file, this looks like an FTP/HTTP server. Once the file has been received, automated provisioning will be initiated and the source file will be archived for future reference.

Presentation layer

The presentation layer (UI) consists of the following components:

• Access Gateway (rProxy)
• Identity provider
• Webconsole and SelfService portal.

Access Gateway

Access Gateway is a native plugin for the Apache web-servers. Access Gateway enables the following functionality with in the OpenIAM architecture:

• Session management.
• URL based access control using OpenIAM. Authorization service enforces access across OpenIAM applications, API endpoints, and third party application, being proxied, through Access Gateway.
• SSO to applications which don't support SSO standards such as SAML2, oAuth 2, and OpenID connect using the following:
  • Header injection - allows dynamically setting headers into the application.
  • Form fill - allows dynamically filling a form.
  • URL rewriting, so that applications are rendered through the proxy.

Identity Provider and authentication

The Identity Provider (IdP) is an integral part of the UI layer. It ties together the OpenIAM UI by providing a common authentication layer. It also providers federation services by providing support for the following protocols:

• SAML 2
• oAuth 2
• OpenID Connect.

IdP also supports token translation so that an authenticated user can seamlessly use applications which require SAML, oAuth, OpenID Connect, and JWT. A person who authenticates and uses SAML for one application can then use oAuth for other applications and vice versa.

The IdP interface can be configured to utilize a number of authentication options which include:

• Certificate based authentication.
• OTP using SMS/E-mail or Mobile app.
• MFA using Push notification.
• Social authentication.

These authentication options can be integrated with Adaptive authentication which allows a variety of factors such as IP, new device, roles, etc. to be evaluated during the authentication process.

Administration portal

OpenIAM provides two out-of-the-box applications:

• Webconsole (system configuration and administration)
• SelfService portal.

Webconsole leverages the IdP for authentication and allows administrators to configure OpenIAM solution. Administrators can perform common tasks such as:

• User management
• System configuration
• Entitlement configuration (setting up roles, groups, etc.)
• Configure authentication
• Configure SSO to application
• Configure synchronization, reconciliation, and provisioning
• Configure workflow
• Manage authentication tokens. They can view and if needed, revoke tokens.
• View audit logs

SelfService portal

SelfService portal is highly end user focused. It uses the IdP for authentication and allows performing the following tasks:

• Manage profile.
• Provide SSO to applications they are authorized to access.
• Change password and restore password, if the user forgot one.
• Access request and approval.
• Review user access.
• Delegate administration.

The branding of all three (IdP, SelfService, and Webconsole) UI components can be customized based on an organization's requirements.