Security Structure

The security in BusinessPlus is represented by what is referred to as "security structure." This is essentially a hierarchical organization of each type of menu mask, application functionality, database table, etc. Anything that can have security applied against it has a corresponding security object in the structure. The reason for using a hierarchal representation is that it allows security to be applied to a security object higher up the tree and have that security ripple down to the objects below it. This allows access to be granted or restricted at an upper level without having to explicitly address every object below it. For items such as CDD folders or menu masks, the hierarchy is somewhat apparent. However, for data and application security the structure can be a less intuitive.

In order to accommodate a heterogeneous set of security objects, the type of security that can be applied to each security object changes depending on the type of object. I.e., for CDD folders the access is controlled based on Read, Write, Update, Delete and Execute. However, for menu masks the only access that really applies is Execute, since the ability to alter records is handled by the data access once the page or utility is run. For items such as database tables, simply controlling the type of access is not enough because it fails to allow data to be controlled based on specific data in the table. Therefore, filters can be applied to the security objects representing the database tables to further restrict how much or how little data will be made available to that security object.

For most of the BusinessPlus subsystems, the security structure has an intuitive layout. Each subsystem has a root node, and below that are three nodes for Menu, Data and Function access. Below the Menu access node is the BusinessPlus menu structure as it would appear from the BusinessPlus dashboard menu. Below the Data access node is a list of database tables considered to be part of that subsystem. Below the Functions node is a list of application functionality specific to that subsystem.

The following example shows a small subset of security nodes below the Person/Entity and Click Drag & Drill root nodes:

Every user essentially has their own copy of this security structure. All of a user's access is determined by how much or how little of the security structure they have access to at any given time. In this way, the setup of security is more about deciding how much of the structure users will have in their copy than it is deciding what they can or cannot do explicitly.

The example below lists two possible users and their resulting access within the software.

For some aspects of BusinessPlus, more than one node in the security structure may be required for access to a given CDD report or page/mask. In the example above, access to PEUPPE is controlled by menu security on that mask and access to the data on that page is controlled by access to the PE_NAME_MSTR table.

Common Security

Some of the data in BusinessPlus is considered to be common to many parts of the software. A restriction on this common information extends to all subsystems that reference it. Applying the same Data Access filter to each occurrence of that common information would make security complicated to set up and maintain. To reduce this administrative burden, the concept of Common Security was made part of the role-based security design.

A simplified example of this concept is security on the General Ledger account keys in the software. Account keys are stored in the GLK_KEY_MSTR table. There is a security object for that table stored within the General Ledger subsystem in the Data list. However, the account key is used on a lot of different tables in BusinessPlus. To accommodate that need, there is a Common Security object for the account keys that provides for a subset of the keys to be granted using a filter on that table.

It is important to remember that some tables will therefore exist twice in the security structure. This is to allow the user's access to the Common Security to differ from access to the table itself. For example, a client may want to configure a user's access to update data based on a subset of account keys but not grant the ability to change the account keys themselves.

Granting access to the Common Security object doesn't necessarily grant access to the tables in BusinessPlus. Alternatively, granting access to a particular table does not necessarily grant access to its related Common Security object. Without both the desired table and its associated Common Security objects, the user would not have access to any data in the table.

The following are examples of BusinessPlus tables with links to Common Security objects. A complete list can be generated using the Common Security Listing plugin in the Administrative Console.

Rebuilding Security

Over the course of many years BusinessPlus has grown to have many different and complex security needs. Because of this there are very few centralized paths or standard ways of requesting security. BusinessPlus menu security is requested while displaying the BusinessPlus menu. BusinessPlus data security is requested while fetching the data from the database. CDD functional security is fetched while building the application menus. All of these were merged into one model so that users can centralize the process of setting up security.

To help accommodate this design objective there is a very deliberate separation from the way the security is set up and configured and the way it is referenced by the software. This was done so that the setup itself could be stored in a way that is as flexible as possible while the software could utilize it in a way that does not create a significant performance problem.

Security Objects

The Rebuild Security Components plugin is used to regenerate the entire list of security objects. This is normally only necessary when applying BusinessPlus upgrades.

Security components are built from multiple components:

• Internally predefined base structures
• BusinessPlus menus (based on current Nucleus menu definitions)
• Additional screens (predefined; BusinessPlus screens not modeled in the Nucleus menus)
• BusinessPlus tables (based on current database tables)
• Client-specific tables and masks (e.g., menu options which are not defined in Nucleus (via NUUPJB), or for database tables which are not regular BusinessPlus tables)

Process

The following steps are performed when rebuilding security:

1. The prior security structure, security role and user security XML/XSLT BLOB rows are removed from the IFAS_DATA table. How many rows depends on whether the client is rebuilding a single user, or all the users assigned to a security role.
2. New versions of those XML/XSLT BLOBs are generated based on the current security setup. This is a complex process that starts by converting the security structure to XML and the security roles to XSLT layers. Then, by applying the layers assigned to each user to the security structure, a resulting user's security is generated.
3. For each user the user security XML document is used to determine what changes are necessary in the US_ROLE_OUTPUT table. If the table is empty the software begins inserting all of the user's security into the table. If the table is fully accurate based on the user security XML no changes are made.
4. A broadcast message is sent out to all of the servers in the server group informing them that they should flush their local cache of security information. This may take a few minutes to complete depending on the amount of server activity. Also, this may cause some latency for those users until BusinessPlus can get the newer version of the security information cached again

Reset Security

If changes are made using the Manage Security Structure tool, several internal security-related structures will be reset upon exit. This process involves the removal of cached security data stored within the BusinessPlus database. The Web server farm will also be requested to reload its security so that the changes will take effect for any users connecting to BusinessPlus. For users who are already connected to BusinessPlus, certain types of security changes will not take effect until the user's next web browser session.