> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/understanding-securepass/architecture-overview.md).

# Architecture overview

SECUREpass uses a modular, component-based architecture built on Java and Hibernate. Components are deployed as microservices, so high-throughput components such as authentication scale independently. The platform runs on traditional VM-based infrastructure as well as Docker and Kubernetes, and uses a multi-database configuration separating reader and writer queries for performance.

### Platform components

| Component                                  | Role                                                                                |
| ------------------------------------------ | ----------------------------------------------------------------------------------- |
| **Auth Service** (SPAuth / AuthPage)       | The authentication engine and login page. Handles MFA, SAML/OIDC and token issuance |
| **Admin Portal** (SecurepassAdmin)         | Management console for users, policies, applications and configuration              |
| **Self-Service Portal** (SecurepassSS)     | Employee-facing portal for profile, password and access self-service                |
| **OTP Service** (SPOTP)                    | Generation and delivery of one-time passwords                                       |
| **PAM Gateways** (SPSSH, SPJDBC, SPRADIUS) | Privileged access gateways for SSH/RDP, database and RADIUS access                  |
| **TenantManager**                          | Orchestrates multi-tenancy and tenant isolation                                     |
| **Scheduler**                              | Runs automated jobs — directory sync, dormant-account checks, campaigns             |

> **Diagram needed** — platform components and how they interact.

### Network zones

In on-premises and private-cloud deployments, SECUREpass separates components across security zones.

* **Military Zone / Intranet** — the most secure internal zone, hosting the SECUREpass database, client repositories (AD/LDAP), the Super Admin and Admin portals, the internal Self-Service portal, the internal Auth Page and the authentication-mode services.
* **Demilitarized Zone (DMZ)** — an intermediary zone exposing the external Auth Page and Self-Service portal, the SMS and email gateways, and integration endpoints for third-party applications, without exposing sensitive internal systems.

> **Diagram needed** — Military Zone and DMZ component placement and traffic flow.

### Authentication flow

A sign-in proceeds: the browser reaches the reverse proxy, which routes to the Auth Page. SECUREpass validates the primary credential, evaluates the applicable risk profile, challenges for the required additional factors, issues a token on success, and redirects the user to the requested application.

> **Diagram needed** — Browser → reverse proxy → Auth Page → database → MFA challenge → token → application.

### Multi-tenancy

SECUREpass supports multiple isolated tenants on shared infrastructure. Each tenant has its own data isolation and can carry its own branding, policies and notification settings, orchestrated by the TenantManager. This supports both enterprise multi-business-unit deployments and MSP models.

### Data model

Key entities are Users, Groups and Departments, Applications, Roles and Entitlements, Risk Profiles, Sessions and Audit records. The Converged Identity Access Graph links these into a queryable model of who can access what.

### Security architecture

* Personal data encrypted at rest using AES, and TLS for data in transit.
* MFA enforced for administrator sign-in.
* Token security using OAuth 2.0 and JWT, with PKCE for public clients.
* Tamper-evident audit logging for forensic integrity.
* Periodic internal VAPT testing aligned to OWASP recommendations.

### Deployment topologies

* Single-server or Docker Compose for development and proof-of-concept.
* WAR-based deployment on application servers for production.
* High-availability clusters with database HA and DC-DR topologies for enterprise scale.