Application Security and Access Control

Access to your application

Every enterprise application needs to control who can be given access. It is usually not open to public. The people who can access it are usually its employees, customers, auditors or consultants.

For every person who can access the application, you must also decide which programs this person can run. For a non-trivial application, the number of programs can be in the hundreds. You will usually organise your programs into a set of menus. The items in a menu can also be other menus, so you can define a hierarchy of menus that a user can access.

Security Profile of your users

Besides controlling what your users can access, you may also want to define the how of their access. This includes attributes like :-

• when they can access, eg Monday to Friday, starting from 8am till 6pm. No access allowed on Rest Days and Holidays.
• their Password attributes like its quality (minimum length, number of digits), aging (eg must change after 30 days), recycling of old passwords and maximum login attempts.
• within how many days a new User must log into the application, otherwise the User account will be disabled.
• their resource usage, ie whether allowed to schedule Jobs, maximum active Sessions, maximum open Programs per Session, maximum Jobs and maximum Tasks per Job.
• how long they can leave their Session idle and how often to check for messages and alerts of the user.
• the list of Menus they can access. These will be displayed in the User’s Dashboard.

The above attributes are defined in a Security Profile, which is then shared among many Users. You can only override a User’s accessible menu list. All other Security Profile attributes will be enforced upon the User.

You should create your own Security Profiles that conform to your (or your Customer’s) policies.

Maymyo Users

Maymyo extends the authentication mechanism of Django by defining a model infra.UserProfile to hold additional information of a User.

You create a user by :-

• adding the User using Django. At minimum you must enter :-

  • a unique user name
  • any password but this will be changed later to the user’s Security Profile’s initial password.

• adding a User Profile in Maymyo. At minimum, enter :-

  • which Django User this profile is linked to. This is a 1 to 1 relationship. One User cannot have more than 1 User Profiles.
  • which Business Unit and Department she belongs to.
  • which Security Profile to use
  • when she can start using the Application

Or you can take our tutorial to learn how to create a user.

Access Control to Application Resources

Access Control means who (ie the User) can access what. The what in this case is an Application Resource, which includes many objects besides Programs and Reports. So what we discuss here will apply equally to other types of Resources, which we will discover later.

Programs created using Django’s admin

For Programs which are created using Django’s admin (a contrib module used to quickly create programs that can perform CRUD on our Models), we inherit Django’s Permission access control.

Note

CRUD means Create, Read (usually with Search ability), Update and Delete, aka known as Master File Maintenance in Maymyo.

Note

Django’s Permission access control

Every Model that you create will automatically have 3 permissions, “Add, Change and Delete”. By default, any superuser will have these permissions to all Models. All programs created using Django’s admin will inherit these permission checking, ie if you did not explicitly grant permissions to your Model to a non-superuser User then this User will not be able to access the admin program that maintains the Model. This Permissions does not apply to non-admin Programs (as we do not use it).

Django allows you to either grant these Permissions to the User directly or indirectly via User Groups. The latter will save you a lot of headache if you have many Users. You will first grant the Add, Change and Delete permissions to the Group and then specify the Group(s) that your User belongs to.

As part of installation, we have auto-created Groups for each of our applications. They are named app_label-maint (eg infra-main) and you can use them for your own Users whom you allow to maintain our models.

Maymyo’s Access Control

The above Django Permissions applies only to admin Programs. Maymyo has its own access control against its own Application Resources, which may be a :-

• Application Program - any web page called using an URL
• Application Report - either a Text or JasperReport report, as these are the only 2 Reporting Engines supported (for now).
• Application Command - anything that can be executed on the Command Line (in the Application Server where Maymyo is installed).
• Application Job - comprises a series of Steps that execute many Tasks using the Scheduler. Each Task may either be a Application Report or Command.
• Application Event - designer defined event that may be raised when a transaction has above ordinary values, eg a Payment Transaction involving more than 1 million (this is attached to a Business Rule, so it is triggered by the rule)
• Business Rule - designer defined Business Rule attached to a Transaction. Similar to Event but has Authorisation mechanism. This is a simple 2 step approval process where a User without permission for a Business Rule makes an authorisation request from her superior (who has permission).

Maymyo access control works in either of 2 methods :-

• a simple Access Level clearance check. Every Application Resource has a Minimum Access Level which is compared with a User’s assigned Access Level. This Access Level is a positive Integer. For example, a Program “X” has a Minimum Access Level of 200. This means that only Users with Access Level 200 and above may access it. So even though a User may see this program on her menu, she will be stopped from running it.

• an Access List may be defined for an Application Resource. This will override the Access Level checking. The designer will define for a Resource a field which is the Key to the Access List and up to 5 other fields to be used as Attributes.

  • This Key allows you to define many Access List for one Resource, one each per Key Value. You may also use the ALL-ROWS wildcard to define a catch-all Access List. This is used when a particular Key Value has no Access List defined.
  • The Key field is used only for Business Rules and Application Events. For all other Resources you should use the ALL-ROWS wildcard for its value.
  • You can choose not to use the Key field by defining only one Access List using the wildcard ALL-ROWS.
  • the 5 Attributes fields are optional. They are useful for Events and Business Rules only.
  • the designer supplies these Key and Attribute values in a python dictionary (ie a list of Key:Value pairs) during runtime. So these values may not necessary come from the fields of the Resource. It is entirely up to the designer.

How does an Access List work?

• an Access List for a Resource is a list of Roles or Users who are allowed to access it.

• a Role is similar to a User Group. You define which Resources a Role can access and then share it with many Users. This will save you a lot of work defining Access List by Users.

• A User may have 0, 1 or many Roles. She will inherit all the access permissions of these Roles, unless if it is overridden for specific Resources by her own User Access List.

• so an Access List, whether by Role or User behaves the same way. You define an Access List row for a Resource, Role (or User) with a Key Value and up to 5 Attribute values as defined for that Resource.

• what Attribute values to use for a Resource is decided by the designer. But this applies only to Business Rules and Application Events. For the other Resources, we should not be using the Key or Attribute fields.

• For the Attributes, you define in the Access List the Access Values. You may use real values or our wildcards, ALL-ROWS or NO-ROW. For the latter, no access is allowed no matter what.

• When a User wants to access a Resource (which has its Key and Attribute values), Maymyo will look at whether any Access List is defined for that Resource. If none, then it will use the Access Level mechanism described earlier.

• If there is at least 1 Access List defined for that Resource, then we will look for the User’s Access List for that Resource. If none, then we will look for Access Lists for all the Roles that this User have.

• So if neither is found for the User, then she will be denied access.

• But if an Access List is defined for that User, it will be used, otherwise we will check the Access List of all her Roles until the first one allows her access.

• A User Access List may have start and end datetimes. You can use this to give temporary access to a User, eg for someone who is acting as replacement for the usual User who is on leave.

• How we check the Key and Attribute values

  • with the Key Value of the Resource, we will look for the Access List with this exact Key Value. If none is found, then we will fallback on the ALL-ROWS Key Value. If both not found, then the User (or Role) has no access.

  • When an Access List is found, we will check the Resource’s Attribute values against the Access List’s access values, one by one. All Attribute values checked must return True, ie they are logically ANDed together. If any one returns False, then access is denied.

    • When the access value is ALL-ROWS, then we return True.
    • When the access value is NO-ROW, then we return False.
    • When either the access value or Resource Attribute value is null (or blank), then we return False.
    • When the access value is numeric, then we check that the access value is greater or equal the Resource attribute value. (ie access_value >= actual_value)
    • When the access value is a numeric or string range, “20-30” or “AAA-CCC”, then we will check that the Resource attribute value is between these 2 values, eg 20 <= access_value <= 30.
    • When the access value is a single string, eg “ABC” then we will check that for equality of the Resource attribute value against the access value, eg access_value = ‘ABC’
    • When the access value is a comma delimited list, eg “A,B,C”, we will check that the Resource Attribute value is a member of this list, eg access_value in (‘A’, ‘B’, ‘C’)

  • You (as the Administrator) may decide to toggle the results of the Attribute checks. What this means is that the result of the check above is negated (except for the first 3 items, ALL-ROWS, NO-ROW or when either is null), ie True becomes False and vice-versa.

Example usage of Access List

• you have a special Report that only the CEO can access. Define a single Access List for this Report with the CEO’s user. Key Value should be ALL-ROWS.

• We (as the designer) have a Business Rule called “RECEIVE-PAYMENT”. This Business Rule is checked during the Selection for the “Receive Payment from Customer” transaction. We decide to use the Product Code (of the Customer) as the Key field and Receipt Amount as the Attribute value. Your business may have Products called “GOLD” and “SILVER”. “GOLD” customers are high net-worth, so we will not be surprised if they routinely pay us more than 100,000 but for “SILVER” customers this would be extra-ordinary. Assume we have 2 Roles, “CLERK” and “MANAGER”. So we should define the Access List for this Business Rule as follows :-

  1. Role “MANAGER”, with Key Value “ALL-ROWS” and Attribute 1 “ALL-ROWS”
  2. Role “CLERK”, with Key Value “GOLD” and Attribute 1 “1000000”
  3. Role “CLERK”, with Key Value “ALL-ROWS” and Attribute 1 “100000”

  We will be toggling the check for Attribute 1. This is because we want to use the “Less Than” operator instead of the normal “Greater or Equal”.

  The effects of these will be :-

  1. Users who have the Role “MANAGER” has permission to perform Receipt of any Amount.
  2. Users who have the Role “CLERK” can perform Receipt for “GOLD” customers for Amounts up to 999,999.99 and all other Customers, up to 99,999.99. If the amount is Equal or more than this threshold, she will have to request for an Authorisation from her Manager to allow the transaction selection to go through.
  3. You should not have users having both Roles. In this event, the more powerful Role will dominate.

  What the above means is that “GOLD” customers will surprise us only when they pay us more than 1 million while for other customers we set this threshold at 100,000. Notice that the wildcard ALL-ROWS will apply to Products which are not “GOLD”. This is a good practice to avoid disallowing access when new Products are added.

  We would usually link the above Business Rule with an Event to allow other Users to register the attribute values of this transaction, above which they want to be informed (via our Messaging service).