Application Security in Mifos

Introduction

Currently in mifos (up to version 1.5), there exsits a homegrown solution for providing authentication and authorization for mifos application users.

As part of a spike on moving to spring security, we need understand and document what type of application security functionality currently exists.

How it works (Generally)

Mifos currently allows administrator users to create new roles and assign a name to this role. When creating a role, there is a set of 'activities' that can be associated with a given role. These are the 'permissions' for users that are assigned a given role. An application user can be associated with many roles.

Authentication

Application users details are currently stored in PERSONNEL. These are related to ROLEs through PERSONNEL_ROLE. When a user logins with username and password, their details are verified agasint those in PERSONNEL.

PERSONNEL -> PERSONNEL_ROLE -> ROLE -> ROLES_ACTIVITY

Request Flow

  1. BaseAction.execute
  2. LoginAction.execute #. take username and password off LoginActionForm #. PersonnelBusinessService.getPersonnel(username) #. Personnel.login (validates password is correct and returns UserContext for storing on request)
    1. is active, locked, is password valid, set flow to blank on successful login
  3. forward to home page on successful login

Authorization

When the application starts up (see ApplicationInitializer) a number of services are programatically initialised so they are available for when the applications starts.

Some of these are security services which are ActivityMapper and AuthorizationManager and HierarchyManager (to do with office hierarchies cause some authorization occurs where the loan_office or logged in user's branch becomes important) is included within the ApplicationInitializer.initialiseSecurity method.

ActivityMapper

When the application initialises, this class is responsible for loading all the 'allowed' methods for each struts action class and are associated with a security constant.

This provides a sort of 'method-level' security at the struts action class level that is checked at each request (see MifosRequestProcessor). If the security constant returned is not zero, then the AuthorizationManager is used to verify application user has 'permissions' to perform the activity.

AuthorizationManager

When the application initialises, this class is responsible for loading all the roles in the application creating a map of activities-to-roles e.g. 91=(1, 2, 3)

Certain parts of the application programatically check if the user is allowed perform the given functionality by verifying logged in application user has valid activity ids (permission) based on the roles associated with the user.

Mifos Request Processing

Filters

  1. DatabaseInitFilter
  2. MifosLogFilter
  3. LoginFilter
    Servlets
  1. MifosRequestProcessor

Summary

In general, application security on mifos is fine-grained, progamatic and not overly flexible/extensible.

If we move to spring security, we need to support the current fine-grained model but achieve this using as much out of the box spring security as possible whilst also solving newer functionality requests like being able to support business rules like 'allow loanOfficer to approve/disbure loans up to x value).

As we refactor/move away from struts actions, we need to implement the same 'security' functionality using spring security so a solution that supports incrementally moving away from current implementation is important.