IDMS Multi-Tier Architecture

IDMS System Architecture: Multi-Tier Implementation

For organizations hosting IDMS in the cloud or requiring additional security controls, the IDMS deployment can be split into different tiers to provide greater control and security. The diagram below depicts a multi-tiered system architecture for the IDMS, designed to segregate functionality and enhance security. The architecture is composed of four distinct tiers: Infrastructure, Application, Web, and Public. Each tier has a specific role and communicates with the others through firewalls, ensuring a secure and controlled flow of data.

Tier Descriptions

Infrastructure Tier

This tier represents the customer's existing internal systems that the IDMS connects to for core services. It is the foundation of the architecture, housing critical components such as:

• Directory (Port 636): The customer's Active Directory or LDAP, which the IDMS connects to for user information.

• Database (Port 1433): The SQL database used for storing identity attributes and transaction data.

• CA Services (Ports 445, 135, 80): The Certificate Authority services used for issuing PKI-based credentials.

• HSM (Port 9004): *Optional: The Hardware Security Module, utilized for secure key storage and cryptographic operations.

Application Tier

This is the central processing layer of the IDMS. It hosts the core server software that performs reporting, automations, identity proofing workflows, and management tasks. The application layer runs on a Windows operating system and uses IIS as its application server. It communicates securely with both the Infrastructure Tier and the Web Tier.

Web Tier

This tier is responsible for hosting the user interface (UI) layer of the IDMS and proxying connections from the client to the IDMS Rest API. It is the component that users directly interact with. All communication between this layer and the Application Tier is secured using Mutual TLS (MTLS) on ports 443 and 444, ensuring both the client and server are mutually authenticated. Further more, all external requests are first routed through the Proxy server before reaching the IDMS server itself.

Public Tier

The Public Tier represents the end-user clients, which are typically workstations or management systems. These clients connect to the Web Tier to access the IDMS for tasks like device programming, reporting, and system administration. This tier can reside on either the customer's intranet or the public internet, depending on the established security policy. All connections from this tier to the Web Tier are also secured via firewalls.

Network and Communication

Communication between each tier is explicitly routed and secured through firewalls. This creates clear segmentation and allows for granular control over network traffic. Key connections and their associated ports include:

• Infrastructure to Application: Uses standard ports for directory (636), database (1433), and CA/HSM services (445, 135, 80, 9004).

• Application to Web: Communication is secured using Mutual TLS over ports 443 and 444, indicating a strong, bidirectional authentication and encryption protocol.

• Web to Public: The final connection is from the Web Tier to the end-user clients, which is also secured via a firewall, protecting the internal layers from public-facing traffic. For IDMS API Access, traffic enters through the Proxy server, which then handles the internal routing to the IDMS API Endpoints.

The Role of the Proxy

The Proxy server serves as an intermediary between the external network (Public Tier) and the internal IDMS server’s REST API. Its primary function is to route requests to the IDMS API Endpoints, but it provides several key security and performance benefits:

• Security: The Proxy acts as a Reverse Proxy, which can hide the internal IDMS server's IP address and technical details from the public internet. This reduces the attack surface by preventing direct exposure of the IDMS server to external threats. It can also perform tasks like SSL/TLS termination, request filtering, and basic traffic inspection to block malicious requests before they ever reach the application server.

• Traffic Management: The Proxy efficiently manages incoming client requests, ensuring they are correctly directed to the appropriate API endpoints.

• Scalability & Performance: In more complex deployments, a proxy can be configured for load balancing, distributing incoming traffic across multiple IDMS servers. This enhances the system's performance and ensures high availability by preventing a single server from becoming a bottleneck.

Enhanced Security Through a Layered, Tiered Architecture

The IDMS system's multi-tiered architecture is a robust security model that improves protection by segmenting functionality, enforcing secure communication, and limiting attack surfaces. Rather than a flat, monolithic design, this layered approach creates a defense-in-depth strategy that makes it significantly more difficult for an attacker to compromise the entire system.

1. Network Segmentation and Reduced Attack Surface

• Tiered Isolation: The architecture physically separates critical components (Infrastructure Tier) from public-facing user interfaces (Public Tier) using a series of firewalls. An attacker gaining access to the public-facing Web Tier does not automatically have direct access to the database or directory servers in the Infrastructure Tier.

• Controlled Access: Firewalls between each tier act as checkpoints, ensuring that only necessary and authorized traffic can pass. This limits the attack surface by preventing lateral movement and unauthorized connections between tiers. For instance, the firewall between the Application and Web Tiers would only permit traffic on the defined MTLS ports (443 and 444), blocking all other communication.

2. Secure and Encrypted Communication

• Mutual TLS (MTLS): The use of MTLS between the Application and Web Tiers is a critical security feature. Unlike standard TLS, which only authenticates the server, MTLS authenticates both the client and the server. This ensures that only trusted, authenticated components can communicate, preventing a rogue or compromised server from establishing a connection.

• Encrypted Connections: All traffic between the Web and Application Tiers is encrypted, protecting sensitive data from being intercepted or read by an attacker on the network.

3. Least Privilege and Functional Separation

• Specialized Tiers: Each tier is designed with a specific, limited purpose. The Web Tier's sole job is to present the UI, while the Application Tier's is to process data. This separation of concerns means that if a tier is compromised, the damage is contained. For example, a vulnerability in the Web Tier's UI would not expose the core business logic or sensitive data processing that resides in the Application Tier.

• Dedicated Connections: Connections are only established on a need-to-know basis. The Public Tier does not need to connect directly to the database; it only connects to the Web Tier. This minimizes the number of open ports and potential entry points into the more sensitive back-end systems.

4. Centralized Security Management

• Firewall Control Points: The firewalls serve as centralized security enforcement points. All network policies, such as port restrictions and traffic inspection, are managed in these locations. This simplifies auditing and ensures a consistent security posture across the entire architecture.