mPass High Level Design (HLD)

Modified on Wed, 27 Mar 2024 at 11:20 AM

Confidentiality Agreement

This document is the property of Cerebra Technologies and may not be reproduced, by any means, in whole or in part, without prior permission of Cerebra Technologies. The document is provided on the understanding that its use will be confined to the officers of your Company, and that no part of its contents will be disclosed to third parties without prior written consent of Cerebra Technologies.

1. Introduction

The mPass authentication server (AS) is an OATH compliant comprehensive solution for enabling Multi-Factor Authentication (MFA) for enterprise applications such as VPN Systems, Outlook Web Access, Active Directory Federation Services (ADFS), Windows/Linux systems or any in house developed applications. mPass AS enables strong authentication via OATH-based One Time Passwords (OTP) via SMS and Mobile apps.one-time passwords.

1.1 Purpose

This HLD documentation presents the structure of the mPass system, such as the database architecture, application architecture (layers), application flow (Navigation), and technology architecture. The HLD uses non-technical to mild-technical terms which should be understandable to the technical/non-technical personnel.

2. Overview

This HLD will:

Present all the design aspects and define them in detail.
Describe the user interface being implemented.
Describe the hardware and software interfaces.
Describe the performance requirements.
Include design features and the architecture of the solution.
List and describe the non-functional attributes like:
1. Security
2. Reliability
3. Maintainability
4. Application compatibility

3. General Description

3.1 Solution perspective

The mPass solution is comprised of several different components. Each component will be deployed based on the project requirements. The mPass authentication server (AS) is the primary and central component of mPass solution.

3.2 Design Goals

The following are the primary design objectives:

1. Support diverse enterprise systems/applications for enabling MFA.

2. Secure OTP generation based on standards.

3. Support various MFA forms such as SMS OTP, Mobile app OTP, OTP via email, Push Authentication

4. Facilitate workflow/policy-based MFA process.

5. Integrate with diverse external systems such as directory servers, SMS, and Email gateways.

6. Be highly scalable & reliable to support a large user base.

4. Design Details

4.1 Design artifacts

The design artifacts include five major parts: the architecture, the user interface design, the external interface, the database, process relation, and automation.

To make these designs easier to understand, the design has been illustrated in included diagrams.

4.2 Solution architecture

4.3 Modular Architecture

Following are the various modules of the mPass solution to facilitate MFA for enterprise applications.

Modular Architecture
Major Subsystems
Subsystem Name	Primary Function/Role
mPass Administration Portal	Web-based application for MFA management for the mPass administrators
mPass User Portal	Web-based application for enterprise users to enroll mobile authenticator app
Soft token mobile applications	Android and iOS based mobile apps to generate Time-based One-Time passwords (OTP)
mPass OWA	mPass Agent for Outlook Web Access to enable MFA during login
mPass Windows	This component will enable MFA for Microsoft Windows
mPass Linux	This component will enable MFA for popular Linux Variants such as Ubuntu, Redhat and CentOS
mPass RADIUS	mPass RADIUS server will provide authentication services along MFA for RADIUS clients such as VPN gateways, firewall authentications etc.
mPass ADFS	mPass Active Directory Federation Services (ADFS) will enable MFA services for Microsoft Server ADFS
mPass Web API	The Web API facilitates MFA for any custom developed applications via standard HTTP interface.
SAML 2.0 Services	The mPass SSO 2.0 component acts as a SAML 2.0 compliant Identity provider and also enable MFA during authentication
Channels	Channels are like application firewalls which control integration between enterprise systems/applications
Policies	Policies are a set of rules to control the authentication process
Tokens management	Tokens are virtual components which are bound to the enterprise users. These components are used to generate OTPs during authentication process
Users Module	The users module manage the users details relevant to MFA authentication.

4.4 Technology Architecture

Following are the various technologies/programming components considered to build the mPass solution and its components.

Layer	Considered Programming frameworks/libraries
Front End	XHTML, CSS, JavaScript, ASP.NET
Mobile Apps	Android (Java) and SWIFT
Backend End	Java, Spring, Spring Security
Application Runtime	JRE 1.8 and above and Wildfly
Database Platform	SQL Server/Postgres SQL/My SQL
OS Platform	Windows Servers, Linux
Component Technologies	C#, .NET runtime, C and C++

4.5 Standards/Algorithms

Following are the various standards/algorithms adopted across various components to build the mPass solution.

	Considered Standards/Algorithms
OATH	Initiative for Open Authentication (OATH) is an industry-wide collaboration to develop an open reference architecture using open standards to promote the adoption of strong authentication. It has close to thirty coordinating and contributing members and is proposing standards for a variety of authentication technologies, with the aim of lowering costs and simplifying their functions
HOTP and TOTP	HMAC based One Time Passwords and Time based One Time passwords. Algorithm specifications to generate One Time passwords.
PSKC	Portable Symmetric Key Container specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.
RSA with SHA 512	Algorithm to generate Public-private keys
SAML 2.0	To exchange user and token information in an SSO based integrations
BCrypt	BCrypt strong hashing function. Clients can optionally supply a "version" ($2a, $2b, $2y) and a "strength" (a.k.a. log rounds in BCrypt) and a SecureRandom instance. The larger the strength parameter the more work will have to be done (exponentially) to hash the passwords. The default value is 10.

4.6 Database design

4.7 Process design

Following is the depiction of the cross cutting mPass components across the various MFA requests from mPass components.

4.8 User interface

The user interface is a typical web application called the mPass administration portal. It is used to manage mPass artifacts such as Channels, Policies, Users and backend configurations.

Apart from the administration portal, another web application should be provided for enterprise users to activate and test the mobile-based application.

User Portal

4.9 Error Handling

Should errors be encountered, an explanation will be displayed as to what went wrong. An error will be defined as anything that falls outside the normal and intended usage.

The error logs should be accessible from the following sources:

1. Administration portal console

2. Server Logs

3. External syslog systems

4.10 Communication Interfaces

There are 6 communication interfaces for the mPass system:

1. An HTTP(S) based interface, which will be used for system administration, user enrollment, MFA authentication services and wildfly administration.

2. UDP based RADIUS interface for RADIUS Authentication.

3. LDAP/LDAPS based interface for enterprise directory server connectivity.

4. SMTP-based interface for sending emails.

5. HTTP based interface for sending SMS.

6. JDBC based interface between the wildfly and the database.

4.11 High Availability & Reliability

mPass central authentication server should be able to be deployable in a multi-node clustered environment. The inbound and outbound interfaces should be able to communicate at a minimum bandwidth of 1Gbps for excellent performance.

mPass Authentication servers can be deployed behind any standard HTTP and RADIUS load balancers, thereby delegating the load distribution and failover to the load balancer.

A redundant database server should be implemented so that if the main database server stops responding, the authentication servers will automatically start using the other database server. The mechanism used for syncing these two databases will be the infrastructure team’s responsibility.

Following is a typical HA deployment setup:

4.12 Security

Following security controls should be available in mPass solutions:

The mPass authentication server web interface access should be segregated into following roles:

Role Name	Description
Super Administrator	Master user role of the system, Users who belongs to this role can execute all the privileges of the system.
Authenticator	Users who belong to this role cannot login to the administration or user portal. These users can only be authenticated by the MPass system.
VPN Local	Users local to VPN system and not present in Active Directory/belonging to domain.
Support	Users with Support role can only view the Request Logs and the Dashboard of the MPass system.
Authenticator and Administrator	User with both Authenticator and Super Administrator role
Operations	User with privilege for the following: Dashboard(without interaction) List Users(Read-Only) Request Logs
mPass Local	User with role similar to Authenticator role, but the password is stored in mPass database, rather than directory server.

2. All communication to the mPass server should be via secure SSL sockets.

3. All passwords stored in mPass should be salted and hashed via Bcrypt algorithms.

4. All invalid password/OTP attempts should be logged, and user should be locked after allowed limits.

5. The mPass system should never allow the same OTP to be used again.

6. Users should be automatically locked after in-active period.

7. Authentication requests to mPass should be restricted based on IP address and API/Shared secrets.

8. OTPs sent via SMS/Email should have a limited validity time.

9. mPass should never log the Users password or OTPs in any of the logs.

10 mPass user portal should be restricted to domain users only.

4.13 Maintainability

Very little maintenance should be required for the mPass setup. An initial configuration will be the only system required interaction after system is put together. The only other user maintenance would be any changes to settings after setup, and any specified special cases where user settings or history need to be changed. Physical maintenance on the system’s parts may be required and would result in temporary loss of data or Internet. Upgrades of hardware and software should have little effect on this project but may result in downtime.

4.14 Solution Compatibility

The mPass solution should be developed using open standards and hence it should be compatible with other systems following open standards.

The mPass solution will be built on Java technology and should be deployable across Windows/Linux/Macintosh platforms.