Role-Based Security

The need to control access to different aspects of the software is a central requirement for all organizations. In addition, the security must be flexible enough to accommodate the diverse and constantly evolving nature of both the client and the software. A role-based security structure facilitates implementing and maintaining security assignments.

Inclusive Security

BusinessPlus uses "inclusive security" which means it does not specifically remove functionality from users but adds to their function abilities. The more security roles a user has, the more access they will have to the software. To control access to sensitive data or application functionality, do not deny access to certain users but simply withhold any roles that would grant access. Understanding this is the key to developing roles that can be reused throughout the organization.

It is also important to consider the long-term maintenance issues that may result from role creation. For example, by having particularly sensitive data or functionality granted in multiple roles, it may become difficult to manage who can and cannot see that data later. What is considered sensitive can vary greatly from client to client. Another reason for the flexibility of this security model is that it allows each organization to structure their roles based on their individual needs.

Access

Security in BusinessPlus involves controlling access to:

• Menu Options — A BusinessPlus menu is a collection of pages, reports and processes grouped by subsystem and then function. Since the menu list is represented to the user in a hierarchical tree it fits nicely into the security structure. The security is on or off for each menu option by granting the "Execute" permission within a Security Role. Access can be granted or denied at either the top level of that subsystem's menu structure or at the very low levels of the menu tree. If two roles are assigned to a user and one grants a menu option and the other does not grant it, the result in an inclusive security model is that the user is granted the menu option.
• Application Functionality — Different aspects of application functionality are controlled by the security structure. This can be anything from executing CDD reports without selection criteria to the ability to print purchase orders. How an application will interpret the levels of access on each of these nodes can be very specific to that application.
• Database Information — Access can be granted to entire subsystem of tables by using the subsystem's data node. Alternatively, access can be granted on a table by table basis and filtered using an SQL Where Clause to provide more specific restrictions. For each BusinessPlus subsystem there are database tables listed below the top-level data object. For many subsystems this will include a combination of transaction, batch and other miscellaneous tables directly related to that portion of the software. Many of the tables will be granted to any user whose job requires them to have access to that subsystem. This can be done fairly easily by granting the top-level data node for that subsystem and as a result granting access to the tables below. However, for some users the access to some of the tables within that subsystem will need to be filtered to control how much of the data within that table they have the ability to view or alter. For each of these tables, security will need to be applied specifically by removing their "derived" status, specifying the desired access and then specifying that access with a filter.

Concept

Imagine having a security role that only allows access to run reports, and another security role that gives access to save reports. In a "most restrictive" environment, the two roles would cancel each other out. However, in an inclusive security model the two roles combine, giving the user the ability to run and save reports.

Using well-designed security roles enables clients to determine which users have access to a particular functionality. E.g., using a role that grants the ability to save reports (called "Save Reports"), a security administrator can easily access a quick listing of role assignments to determine who can save a report. In addition, the administrator can grant a user the ability to save reports without granting other security defined in that role that they were unaware of at the time.

In BusinessPlus, it is always important to remember that security roles work in conjunction with each other and not in opposition. A client may have a set of Payroll reports that they do not want users to be able to see. They can put them in a CDD folder called "Payroll Reports," and create a role called "Payroll Reports Folder" that gives access to that folder. In an organization, some people create reports, others modify reports, while some only run reports. These are frequently not the same people.

Security Database Tables

The following tables are used in storing the role-based security setup within the BusinessPlus database.

• US_SECOBJ_MSTR — This table stores all of the Security Objects from the Security Structure. Everything that can possibly have security applied to it has an entry in this table. Initially, this table is generated from a combination of known security elements such as CDD reports as well as the masks defined in the Nucleus tables and the BusinessPlus tables found in the schema information. The Manage Security Structure plugin allows maintenance and restoration of the contents of this table.
• US_ROLE_MSTR — This table stores the master record for both security roles and Workflow roles. For each role created in the system there should be one entry in this table containing both the Role ID and Role Title.
• US_ROLESEC_DTL — Each security object (US_SECOBJ_MSTR) that has some kind of security explicitly assigned to it in a particular role gets an entry in this table. Security objects marked as "derived" in a security role do not get an entry in this table.
• US_ROLE_DTL — The assignment of both security and Workflow roles to users in the system is kept in this table.
• US_ROLE_OUTPUT — Security information used by BusinessPlus, CDD and the software running on the application server is generated from the above tables and stored in this table so that it can be consistently applied across applications. This table stores the individual security objects, what access the user has to and for database tables the filter information.
• IFAS_DATA — This table is used by a number of BusinessPlus modules for storing binary data. In the case of role-based security, the XML and XSLT representations of the security structure, security roles and user security are generated from role information and stored in this table.

Persisted BLOBs

If the software had to read every table used to set up the role-based security every time it needed to determine a user's access it would make the software extremely slow. Therefore, the software saves the output from those tables into a BLOB stored in the BusinessPlus database so that it does not have to read all the details every time it needs security information. All BLOBs used by role-based security are temporary storage only; they are not found in the system but simply regenerated by the software on an as-needed basis.

The list below contains the IFAS_DATA categories used by role-based security.

Server Cache

The Web server software maintains a number of worker threads for processing requests. One of the ways these threads have been made more efficient is by caching some of the security information so access requests can be fulfilled without going back to the database with each request.

Managing Software Changes

One of the benefits of grouping similar functionality into specific roles is that as the software changes the time and energy required to maintain security is dramatically reduced. Imagine that a new feature is added to an application that qualifies as "Super User" utility. Features of this type are not appropriate for all users but extremely useful for others. In most cases, making this utility available to users would entail determining the security class of the desired users and making the change to that class. If the desired users do not have the same class, this might involve adding that change to multiple classes. The client would also need to make sure that those classes were not also assigned to users who should not have this functionality. Therefore, the seemingly simple task of making a feature available to users can become a real ordeal and mistakes can be very costly.

With the role-based structure, one of two methods can be used to simplify the process. If a class for "Super Users" already exists, the user can view a list of all users assigned to this role. If it is appropriate for those users, security can be granted to that role. If there is no appropriate role already available, a new role can be created that only gives access to that utility. Specific users can then be assigned that role and the functionality will be made available to them.

Managing User Changes

Over time, the nature of people's jobs and duties can and frequently will change. A user's individual job requirement may change in ways that cannot be addressed in their security class without also giving all of the other people with that class the same access. In addition, employee turnover can create security issues. The person filling a position may not have exactly the same security needs as the person who left that position. If the security class was only assigned to that one user, it can be edited, but if not, a new security class may need to be created.

The concept of security roles can help eliminate some of that hassle. Security, such as the ability to print finance reports, can be put into a single role with no other functionality. If an individual's job requirements are changed to include printing financial reports that access can be granted without granting it to everyone else that has that person's current security. Also, the ability to print financial reports can be just as easily removed without impacting any of the other access this person may need.