SuperFinance: Digital Banking Software as a Service (SaaS)

Introduction

In this tutorial we are going to build SuperFinance (SF) – a banking software as a service (SaaS) web application on ASP.NET Core MVC using ASPSecurityKit.

The goal is to let you experience the ease at which a secure multi-user and a multi-tenant web app can be created with ASPSecurityKit.

Watch It as a Build Episode Instead

Business Features

Being a SaaS application, the web app offers bank institutions and customers the following capabilities:

• Self-service interfaces for banking institutions to Setup the bank – including account types, branches, branch staff, and also create and manage customer accounts, perform cash deposit and withdrawal requests.
• Self-service interfaces for banking customers to register, open accounts in any available banks, perform transfers, view transactions, manage account nominees (beneficiaries), etc.

Users

SuperFinance is a multi-tenant system because it allows multiple banking institutions to setup and offer their digital banking services. Understanding the different kinds of users and the privileges each one possesses is fundamental to the security design of the system. It might seem a daunting task to implement the controls required to securely serve following users as per their privileges, but as we’ll see in the tutorial, ASK’s activity-data authorization (ADA) feature makes it super simple and intuitive.

• System Administrator – SF admin who has full access to the entire application and its data being the maintainer of the SuperFinance SaaS itself.
• Bank Owner – A top-most user for a banking institution. Have access to the entire data of her respective bank and can perform all actions available to the bank.
• Branch Manager – A banking staff manager with access to actions on accounts related to her specific branch – including approving new accounts, removing dormancy etc.
• Branch Staff – A banking staff individual with access to actions on accounts related to her branch, but mostly transactional privileges.
• Account Holder – An end-customer who owns an account. She Can create new accounts in any bank available on the platform, transfer funds, view statements, manage nominees, but cannot perform cash withdrawal/deposits on her account – for which she needs bank staff.
• Nominee (Beneficiary) – An end-customer who is appointed by another customer as a nominee (beneficiary) of her bank account. A nominee has only view access to the account on which it’s declared as one. A nominee is also a regular bank customer and can also own one or more accounts in the same bank.

Security Mechanisms

Every multi-user application needs to be secured from unauthorized access to protect the user data it hosts. For a financial app, the importance of security cannot be overstated because leakage of data can result in people losing real money. Leveraging ASPSecurityKit various features, in this first iteration of the tutorial we employ the following security controls.

Authentication

• Credentials based authentication leveraging safe AuthCookie token based sessions. Being an MVC web app, this is the most obvious choice. In case SF is built as API-backend, we would use HMAC token instead.
• If the bank detects a suspicious activity like the hijacking of a customer account, it can block password and the customer will need to reset password to login.
• Bank can impose a password expiration policy by specifying the desired duration (in days) after which all users are required to change password after login before continuing with their activities.

Authorizing Actions and Input Data

SuperFinance employs Activity-Data Authorization (ADA) to isolate and protect data of banks and customers as follows:

• Define a permit set (collection of permissions over entityIds) for different type (role) of users supported.
• Automatically discover and authorize actions and request data mentioned with those actions against users' permit set so users within and across tenants can only touch data they have legitimate access to.

IP Firewall

The power of ASK design is in its generalization – the features are agnostic to the type of application being created. For this reason, you have IP firewall feature available in the MVC web app as well which SuperFinance leverages to give the ability to banks to restrict access to staff portal from only white-listed networks or IPs.

Customers also gets the firewall feature for their individual user contexts.

Two-Factor (2FA)

For the sake of keeping things simple to test for the SF sample created out of this tutorial, SuperFinance implements a simple email-based 2FA mechanism that leverages ASK’s MFA feature. In the real-world application, you can change the 2FA method to SMS or TOTP based – the MFA checks of ASK’s pipeline are agnostic of the method used for multi-factor token delivery.

While 2FA is available for both customers and banking staff users, banks have an option to enforce 2FA on their staff users.

Because banks have an option to enforce IP firewall on their staff, an option to white-list bank’s network is also provided to skip 2FA for the staff when working from an office.

Email Verification

Verifying the email user provides is paramount to keep her account secure. SF leverages ASK’s verification feature to enforce that the user must verify the email before she can access or perform actions on her account. Only change email action is marked with VerificationNotRequiredAttribute so a user can correct email if needed.

Cross-Site Scripting (XSS)

Leveraging ASK’s XSS feature, SuperFinance will deny all requests that contain potentially dangerous characters. Following the guidelines user data (such as name) in emails are injected after proper escaping of potential XSS characters.

Suspension

• Bank can suspend their staff users and the system will deny login to such users. Since customers are independent from the ownership of any particular bank on the platform, banks cannot suspend customers.
• Leveraging entity suspension feature, the bank can however suspend individual bank accounts for reasons such as KYC required, suspicious transaction, and the owning customer cannot perform transfers or create nominee for a suspended account. But customers can view the account and upload required docs for the bank to request removal of suspension. exclusion rules help in configuring which level of employee at the bank can lift a particular kind of suspension. For example, if KYCRequired is the reason, suspension can be lifted even by the BranchStaff, while Freezed accounts require the head office (BankOwner) to lift the suspension.

Try Out the Live Demo

Visit https://superfinance.ASPSecurityKit.net to play with a live demo based on this sample.