mPass High Level Design (HLD)

Modified on Wed, 18 Sep at 9:37 AM


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:

  1. Dashboard(without interaction)
  2. List Users(Read-Only)
  3. 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.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article