||1/4/2012 4:53:05 AM
Defining "Who sees what" and "who does what" are the two important aspects of access control in any software application.
"Security" is a much larger subject, but this article focuses on just the access control aspects of Security in a software application.
The Older Paradigm - Roles and Page level access controls
When you build a custom application for a specific customer, the access control policies of the organization are often defined upfront as part of the requirements phase. Depending on the vertical, domain and the specific organizational structure of the business, first the roles are defined. And then each role is given access to a set of screens, forms, pages and reports. What role A sees might be different from what role B sees. What role A can do could be different from what role B is allowed to do. Of course, certain areas in the application can be accessed by multiple roles. While building software products (used by several customers), the roles are often generalized and predefined. The various access control policies of the product are often hard coded in to the roles. The customer will be able to assign one or more roles to their users.
The new paradigm - Privilege based Access Controls
In the new paradigm, before doing any action (including showing something on the screen - which is the View action), you check / demand for the privilege to view that information or do a certain action. It could be standard actions such as view, edit and delete or special privileges such as "Access to History Data" or "Access to information or content created by people other than myself. In the new paradigm, a user / roles privileges are resolved during run time - not hard coded at design time. This allows the product developer to complete the development just by demanding the necessary privileges at each step, without having to worry about the users and roles in the system.
Mapping Privileges to Roles
By enumerating the various privileges (entity wise or form wise standard privileges as well as special privileges) in an administration screen, we can allow the end customer to map the privileges to any specific role, during run time. This takes care of dynamic changes in organizational policy. This also allows the end customer to create completely new roles (not originally envisaged by the product designer) dynamically during actual usage and map a set of privileges to these new roles using an admin screen.
For example in a HR product, the product might have default roles such as "Employee" and "Manager" whereas a customer may create a new role called "Team Leader" or "Mentor".
Subsequently, users can be assigned with one or more roles (including new custom roles). So when a user is using the system, the application can resolve who the user is, what his or her role is, what the privileges of the role are - all during run time. So before a particular action, the application can simply check whether the required privilege is available for the user and proceed. While this may seem little challenging from the software design/development front, it will bring in lot of flexibility for the customers.
Relationship based Privileges
Many a time, mapping privileges to roles and assigning roles to users is also not adequate. Let us illustrate this with an example:
firstname.lastname@example.org has logged in to a performance management product. She has been assigned the role of a "Manager" and a set of Privileges have been assigned to this role. For example she can add certain new skills in the skills master, which another user with an "Employee" role cannot do.
But the real challenge however is in defining what she can and cannot see and what she can and cannot do with respect to the performance appraisal ratings of various employees.
Out of the 300 people in the organization, userX, is a "Primary Manager" for 4 employees, "Co-Manager for 5 employees", "Mentor" for 5 employees, "Department Head for 40 employees", and "Peer