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 improvements. 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 enterprise. These organizations had and continue to have significant investments in these solutions as they were complex, expensive to deploy and expensive to maintain (i.e., high total cost of ownership).

Primary drivers for IAM in those days were related to automation and costs 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 improving 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 applications 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 shared services.
• Customers can enable business functionality as needed

Logical Architecture

The diagram below provides a high-level 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.

The core functionality in OpenIAM is provided by the service layer. The UI is a client to the service layer.

Service layer and infrastructure components

In the diagram above, the boxes in blue represent functionality provided by OpenIAM. The boxes in grey 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.

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; an essential principle in developing micro-services. 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 RDBMS. Redis is another critical component in the OpenIAM stack. It is 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

Activiti is a 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. Functionality such as scheduled tasks, attribute rules, pre and post processes can be implemented programmatically, and Groovy script provides this functionality. Groovy script can also be combined with the workflow engine to create an open framework where new business rules and process can interact with both internal and external resources.

Scheduler

The IAM platform allows for the creation of scheduled tasks. Examples of commonly used 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 (OOB) scheduled tasks which can be customized. Customers can also define their own. Scheduled tasks can be created using either Groovy script. The frequency of scheduled tasks is controlled through a CRON expression. The OpenIAM scheduler framework allows for 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 IoT framework. The device manager enables the registration of devices such as phones, tablets, etc. with OpenIAM. The registration process allows us to control which devices can be registered and which cannot.

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 the OpenIAM solution.

Flyway

Flyway is a database versioning and migration component. It is 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 the use case OpenIAM is being used for. 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 (IdM) Services

Identity management and governance requires integration with both source and target systems. To enable this, OpenIAM provides several services which include: The IdM services provides functionality which is specific to identity management and governance. They include services such as:

• Provisioning and de-provisioning along with corresponding Pre and Post Processors
• Synchronization - provides functionality used to import / synchronize data from an authoritative source such as your companies HR system such as Workday and SAP HR. Synchronization can also be used to load data from others 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 synch. If they are not in synch, then rules can be defined to take appropriate action.
• Connectors – Are services which allow communication with business applications to support provisioning, de-provisioning, synchronization, and reconciliation operations. During provisioning or de-provisioning operations, 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 business application.
• Source Adapters – Are a special type of connector 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 (UI)

The presentation layer consists of the following components:

• Access Gateway (rProxy) – Reverse proxy
• Identity provider
• Admin and self-service portal

Access Gateway

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

• Session management
• URL based access control using the OpenIAM Authorization service – Enforces access across the OpenIAM applications, API end points, and third party application which are being proxied through the access gateway.
• SSO to applications which don’t support SSO standards such as SAML2, oAuth 2, and OpenID connect using the following:
  • Header injection – Ability to dynamically set headers into the application
  • Form fill – Dynamically fill 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

The 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 for a variety of factors such as IP, new device, Roles, etc. to be evaluated during the authentication process.

Administration portal

OpenIAM provides two OOB applications: • Webconsole (system configuration and administration) • Self-service portal

The Webconsole leverages the IdP for authentication and allows administrators to configure the 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
• Authentication token management – Administrators can view and if needed, revoke tokens
• View audit logs

Self-service portal

The selfservice portal is end user focused. Like the Webconsole, it uses the IdP for the authentication and allows end user to perform the following tasks:

• Profile Management
• Single-sign-on to applications they are authorized to access
• Change password and forgot password
• Access request and approval
• User access reviews
• Delegated administration

All three (IdP, Self-service, and Webconsole) UI components can be re-branded based on an organization’s requirements.