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 can be segregated into the following tiers:

• User interface (UI) Layer
• Service layer
• Database layer.

In the diagram above, the boxes in blue represent functionality provided by OpenIAM. The boxes in gray are infrastructure components included in the stack, which are shared across the platform. Each contains a wrapper service layer to enable appropriate integration into the OpenIAM platform

The service layer provides the core functionality in OpenIAM with the UI being a client to the service layer. Below, one can find an explanation for each and every service layer.

Messaging

RabbitMQ is used for messaging. All services communicate with each other through the messaging engine. This allows services to be decoupled from each other. This is an essential principle in developing microservices. For example, if the provisioning service wants to know which privileges a user has, it will send the request to the authorization service over the message bus. Similarly, once the provisioning service has determined its actions, it can send appropriate events to the provisioning connectors and audit service using a message queue. Each of these services communicate with each other asynchronously.

The message bus is a critical component of the OpenIAM architecture. It enables the following:

• Scalability of specific micro-services.
• Flexible deployment architecture - certain services can be moved to different hosts or subnets as long as they are able to communicate with each other using the messaging engine. This is particularly important in provisioning cases where target systems can be located in different subnets.
• Improved responsiveness - operations can be processed asynchronously.

Redis cache

Redis is an in-memory data structure cache implementing a distributed, in-memory key-value database with optional durability. Redis is also used as second level cache in the OpenIAM persistence layer for accessing the Relational Database Management System (RDBMS). Redis is another critical component in the OpenIAM stack. It's used to cache objects in both the service and UI layers to improve performance by reducing the need to access the backend repository.

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.