Global

# A centralised authorization module

The security policies and techniques discussed [[infosec|in this page]] require many different mechanisms to be managed and configured. For instance, these settings may include

* geo-IP based restrictions: which countries will we whitelist? Global or per-user? (refer [[infosec#Geo-IP-based-access-rules|this point]])

* on-leave or out-of-office blocking: will a user on leave be allowed access to his account on the systems? (refer [[infosec#Out-of-office-notifications-leave|this point]])

* two-factor authentication settings: global and per-user (refer [[infosec#Two-factor-authentication|this point]])

* settings about authorisation limits and privileges based on physical location, globally and per user (refer [[infosec#Authorisation-based-on-source-location-and-device|this point]])

* global settings about allowing access to various resources from poor-reputation IP addresses: will we allow payment authorisation if it comes from a known black-listed anonymiser or fraud-tainted IP address? (refer [[infosec#Track-remote-IP-address-reputation|this point]])

Various such controls, both global and per-user, will need to be managed by the admin team. We therefore need a separate administration module for this.

## Meta-data store

The authorisation management system will need to store authorisation parameters, or meta-data, somewhere.

MS Active Directory or an LDAP repository should be used for this. The schema of the AD or LDAP can be extended to add proprietary attributes and their values. Such extensions must be done to store the meta-data.

Custom-built applications must be designed to read authorisation parameters and limits from the AD/LDAP repository.

## Maker-checker workflow

Access control and rights must be managed through a minimum of a two-step workflow, where one executive makes the changes and another executive approves them. This workflow must be built into the management system.

It is recommended that these authorisation management operations are not executed by members of the IT team, but by functional managers of various departments, or the HR department.

## Design of authorisation architecture

Before the software for the authorisation management system can be designed, the authorisation architecture which we will use in organisation must be designed. This architecture will answer all the questions like:

* Will we control access to voucher entry in the financial accounting system based on voucher value? If yes, how many levels of access restrictions will we support, for different value ranges?

* Will we support access controls on voucher editing in the financial accounting system based on remote IP reputation?

and so on.

Essentially, this architecture will break down the entire information system into separate applications, then into operations within each application, and then specify the kinds of authorisation controls which will be implemented for each operation or group of operations, together with the attributes (*e.g.* value of voucher) based on which these authorisation controls will work.

Access controls will be at two levels, as can be seen from the examples above:

* at the **operation** level: who can perform voucher entry?

* at the **secondary attribute** level: who can perform voucher entry for vouchers valued higher than INR 25,000? Who can sanction purchases meant for the Surat Depot? (Here, the voucher value or the depot location is the secondary attribute.)

This authorisation architecture will need to be designed before the authorisation management system can be designed. The designers will need to take a call on whether access control based on secondary attributes is required at all. For all access controls, designers will need to group users into groups or roles based on similarity of access privileges. All these things are part of authorisation architecture.