Security Access to System Data and Function
It is no surprise that enterprise-level systems with hundreds of different functions present many complicated challenges. Managing various levels of access to data and functions within the system for different types of users is one of these challenges, and one that people outside the field may not have given much consideration. There are thousands, maybe hundreds of thousands, of users that could be using a system . This can lead to potentially hundreds of groups of users, each needing to be able to only access different sets of functions and data. It could easily take hundreds of hours to set up a system’s security if one had to approve each point of access for each individual user of the system. A high-quality solution to this challenge is non-negotiable; sensitive information is often stored somewhere in these systems, making security a top priority.
Security access generally happens at two levels: functions and data. Having access to certain functions means that a user is able to perform certain actions within the system. For example, an administrator may be able to add a new faculty member, while a student would not have access to that function. This seems simple enough, but consider eMedley: this is a comprehensive platform comprising a myriad of different products and subsystems. Each of these has hundreds of interfaces but let us consider just one of the subsystems: eduCATE, the learning management system. Some of its functionality includes the course feed, the gradebook, the attendance tracker and a vast multitude of reports. Each of these interfaces has several functions: in the gradebook, users might be able to add grades, edit grades, delete grades, curve grades, create new columns, etc. For each of these functions on each interface, different users need to have different levels of access so that, for example, students cannot go in and edit their own grades. One can imagine the level of complexity when this is extrapolated to all the subsystems/products.
Which functions a user has access to are determined by their “access level.” Access levels are generally defined based on a user’s job function or role. Thus administrators have a certain access level, instructors have one, and students have one. Assigning access levels to a relatively small number of groups such as this makes it easier to manage. Of course, custom access levels based on specific job groups can then be built on a needs basis.
Access to data is generally managed through the concept of “permissions.” This comes into play where a user has access to a function such as “manage students” but needs to only have the ability to manage just some of those students. Continuing with the example of eduCATE, instructors would need the ability to view and grade data for all students, while schools would want students to only have access to view their own grades but not each other’s grade data. So, if a user has access to some students, they may only have a set of approved functions that they can perform on the data for those systems (e.g. a user may have access to view and edit but not delete).
This obviously introduces another level of complexity as the administrators need to have intuitive interfaces where they can not only manage access to certain data for certain users but also designate the specific functions that they can perform on that data. The considerations for evaluating a system in terms of its user access management capabilities are as follows:
- What level of granularity and control is offered to system administrators to manage different levels of access to functionality and data?
- How intuitive are the interfaces to manage permissions and levels?
- Can system administrators set up access for a large user base quickly and efficiently?
- Does the system have built in intelligence to determine inheritance of access ?
- Does the system have default access levels that can handle the vast majority of requirements thus keeping security management work cost efficient?
- Can the system handle complex security checking for a user without negatively impacting system performance?