Security Roles

Security roles are made up of the specific security granted to the different security objects within the structure. By default, all of the objects are marked as "Derived." Derived security objects inherit the security of the first parent object that is not derived. If none are found, no access to that security node is granted with a particular role.

The security settings for a specific role may change depending on the type of security object. For example, when viewing Fixed Asset menus, the user may only see one checkbox for "Execute" as opposed to Fixed Asset Data that has checkboxes for Read, Write, Update, Delete and Execute.

Naming Convention

To help keep track of roles, it is a good idea to develop a naming convention. Roles are identified by two pieces of information. First, the Role ID should provide the unique identifier for the role. Second, the Role Title should provide a description of the role. The Role ID can be up to 16 characters long and the Role Title can be up to 30 characters long. Use these two identifiers to create a naming convention for roles that makes it easier to identify their purpose without necessarily digging into the details.

If the Role Title provides a meaningful name for the role, the Role ID can then be used to help give an indication of what type of role it is. For example, each Data Access security role may have included "DATA" in the first four characters of each of those Role IDs.

Using a good naming convention will also make it easier to distinguish between new roles and those that existed in previous versions or as part of the security rollover. Whatever naming convention is selected, be sure to document it to help ensure that it will continue to be used as security is maintained over time.

Setup Approaches

Below are some of the common setup approaches and their advantages and disadvantages.

Fewest Possible Roles

This approach attempts to accommodate security by creating the least number of security roles possible to meet the organization's needs. Frequently, this results in somewhat large and complex roles many of which will mirror positions within the organization.

One Role Per User

This approach creates one security role per user, typically using a naming convention that matches the user's BusinessPlus login.

One Role Per Position

This approach takes each position type within the organization and creates a single security role that handles their access to data, CDD folders, menu masks and application functionality.

One Role Per Security Element

This approach creates one security role for each discrete security element. This may be individual application functionality, such as the ability to create CDD reports, or access to a single or subset of CDD folders.

Common Security Needs

This approach involves evaluating the current security needs to look for common security access both horizontally and vertically. This requires reviewing security needs that span across positions within a department and across the organization. With this information, security roles can be created that grant smaller portions of security and reused across the organization. This allows access to be granted in layers to the users and reduces the need for excessively complicated or numerous roles. PowerSchool recommends using the Common Security approach.

Creating a New Role

To create a new security role, use the "New" icon in the toolbar. Enter the new Role ID and Role Description for the role. After entering those two values the specific security desired for this role can be set in the Security Object Tree. Once all of the desired changes are made the role will be created by using the "Save" button on the toolbar.

Using Existing Roles

Unless setting up security for the very first time, the user will have existing roles to contend with. These roles will most likely come from one of two places. First, if the user was on a version prior to 7.9 they most likely had security roles in place to provide access to CDD, Documents Online or other PC applications. Depending on how they set up these roles, they may or may not still meet the organizational goals.

Second, if a Security Rollover was performed when first installing 7.9, the client may have a series of roles with the naming convention of "USERID__R," where "USERID" was an existing BusinessPlus User ID. Due to the differences between the inclusive nature of role-based security and the exclusive nature of its predecessor, the only way to create a role structure truly representative of the old security was to enclose all of the user's previous security into one role.

In both cases, the roles are actively used by at least some portion of the users. It is not recommended that the client remove them or their assignments during normal working hours. Instead, they may need to leave them in place until the new roles have been created and assigned and then plan on removing them as part of a general clean up at a later date.

Copying Roles

An optimum Security Role design should involve the least possible role overlap. Making good use of layered access and use of discrete reusable security should allow a single role to be reused by many different types of users of the software.

Features are available to copy and paste role information from an existing role into a new role or even replace the role setup of an existing role.

In order to copy a Security Role, browse to the role that needs to be copied and select the "Copy Role" menu item from the Options menu. To create a new role, select the "Add" button from the toolbar and then choose the "Paste Role" menu option from the Options menu. Then alter the Role ID to have a unique name and save the role.

To replace the security setup of an existing role, browse to the Security Role that needs to be replaced and select "Paste Role" from the Options menu.

Note: Pasting the role information onto an existing role will replace that role's setup with the new role security. This should be used sparingly and may have undesirable consequences. Once the user saves a replaced role, there is no restore option for the role and its prior setup will be lost. A rebuild of that role following this change is required.

Menu Access

For menu access determining what a user's resulting security will be is fairly straight forward. Any role that provides access to the BusinessPlus menu mask will enable that mask for the user. Initially, no access is granted to any menu options. However, once Execute access is granted to that menu option it will be accessible. Also, since the menu portion of the security structure is represented in the same hierarchy as it is used by the software granting access to, a top-level menu will result in granting access to all child nodes of that menu. Of course, removing the derived option from a child menu will override the access granted by a parent of that menu option.

Additionally, the more roles with menu access granted assigned to a particular user, the more menu options that user will have available to them. The chart below lists four masks and how two different roles would have interpreted their access. Remember that Role-Based security is inclusive so even if one role does not grant access, another role can undo that restriction by granting access to that menu. When a menu has not been granted any access at all either by itself or from a parent node in the Security Structure then the user will not have access to that menu.

Application Functionality

Application Functionality is very similar to the Menu Access. One difference is that some functions include all five types of access (Read, Write, Update, Delete, and Execute). The chart below shows the resulting security for different functions depending on role assignments.

BusinessPlus Data

Determining Data Security is more complicated. The software has to determine if the user has Read, Write, Update, Delete, or Execute access per table. This is done by checking not only the table itself under its subsystem data node, but also any related common security items. Once that is done, any filters that have been written are merged to create one SQL Where clause that reflects the application of one or more roles.

Common Security & Where Clauses

Common security settings allow "Where clauses" to be written for tables within roles. Access can be further restricted to tables and linked tables based on a combination of common settings found in all roles assigned to the user.
Below is an example of the Edit Where Clause screen. Note that the Where clause has been written for the Read attribute of the associated table, the GLK_KEY_MSTR. It is possible to include Where clauses for each of the attributes of the table: Read, Write, Update, Delete, and Execute.

Not only are the tables listed available for restriction based on the Where clause, but the linked tables are restricted as well. See the example below for reference in how linked tables might be restricted. The example shown does not include each link possibility, but rather an example of the way tables are linked.

General Ledger is broken down into Ledger Security, Account Key Security, Object Code Security, and Budget Version Security.

Ledger Security
(glg_gen_mstr)                        
glg_gen_mstr                        
glk_key_mstr                        
glo_obj_mstr                        
glba_budact_mstr                        
bd_eqpt                        
bd_misc

Account Key Security
(glk_key_mstr)                        
glk_key_mstr                        
glba_budact_mstr                        
bd_eqpt                        
bd_misc

Object Code Security
(glo_obj_mstr)                        
glo_obj_mstr                        
glba_budact_mstr                        
bd_eqpt                         
bd_misc

Budget Version Security
(glg_budg_dtl)
glba_budact_mstr

An SQL "Where clause" can be entered to restrict access to specific portions of the BusinessPlus data. Each common security item corresponds to a database table, so any column within that table may be used to control security. Below are some simple examples of security that can be granted using the General Ledger common items.

These concepts may be combined to produce security that is more complex. Each user may be assigned multiple roles, so it is generally preferable to create simple roles with discrete units of functionality and combine as needed by assigning all relevant roles to the users.

In addition to the common security settings, it is necessary to grant access to each table that will be directly accessed by the user. Alternatively, access may be granted at the subsystem level, allowing access to every table within the subsystem. Any additional restrictions defined at the common level will also be applied, regardless of whether access was granted at the table level, the subsystem level, or even the global BusinessPlus level.

In the example shown below the Purchasing common security settings are shown.

Purchase Orders PRs (pop_pv_dtl)                         pop_pv_dtl                         poi_item_dtl
Purchasing Security Codes (pos_sec_mstr)                         pos_sec_mstr                          pop_pv_dtl

Allow Entry of Set ID

The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to override the Batch Seed value and create a unique seed value.

Masks and Data Set Names

The following are masks and their corresponding data set names used for security.

Setup Examples - Security

Simple Table Access

In this example a single table is selected with no common links and apply two roles. Two roles are used in this example to show an increasing complexity of security between this example and the two that follow it.
Role A: Grants Read access to the CD_CODES_MSTR.
Role B: Does not grant any access at all to that table.

A Simple Filter

This example shows the result of a single filter on the same table from the prior example.

Role A: Grants Read access to the CD_CODES_MSTR but only for the printer codes.
Role B: Does not grant any access at all to that table.

Multiple Filters

This example will show the result of two roles that both grant Read access to the table and both have filters defined. The "OR" that is added between the two filters will result in both subsets being available to the user. This is done to ensure that the result of two filtered roles will always be Inclusive.

Role A: Grants Read access to the CD_CODES_MSTR but only for the printer codes.
Role B: Grants Read access to the CD_CODES_MSTR but only for the seeds.

Common Security

This example will show the resulting security when Common Security is defined for a particular table. To show the impact of a user's security with and without the Common Security granted on the table, the results will be shown in two parts. In the first part the user does not have any access to the GLK_KEY_MSTR because no access has been granted to its Common Security items. The second example shows how a second role has provided the required Common Security. As a result, the user has Read Access to the GLK_KEY_MSTR.

Role A: Grants Read access to the GLK_KEY_MSTR table under the General Ledger Data node.
Role B: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items.

Without Role B:

With Role B:

Common Security Filters

Filters can be defined on both the BusinessPLUS tables and the Common Security tables. The result for the user is a filter that enforces all of the restrictions within that role. Because the Common Security is enforced in addition to the individual table filters, the filters within the role are joined by an "AND" instead of the "OR" that is used between roles.

Role A: Grants Read access to the GLK_KEY_MSTR table under the General Ledger Data node with a filter on the GLK_KEY column.
Role B: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items. Also, a filter has been placed on part 1 of the "Account Key Security" Common security.

Merged Filters

When there are multiple roles with filters defined for the same Common Security or BusinessPLUS Data Table the result is a security filter with the common security filters merged with an "OR," the table filters merged with an "OR" and the two sets merged with an "AND."

Role A: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items. Also, a filter has been placed on part 1 of the "Account Key Security" and a filter on the Org. Key of the GLK_KEY_MSTR table.
Role B: Grants full access to the "Account Key Security" Common Security item with a filter on part 1 of the "Account Key Security" and a filter on the Org. Key of the GLK_KEY_MSTR table.

Unfiltered Override

Role Security will merge the filters of multiple roles for the same table. However, since Role-Based Security uses the concept of inclusive security when a user has unfiltered access to the table, the security removes any other filters on the table and the user has access to all records with no restrictions. The result of having access to both a filtered set of rows and all rows would always be all rows. The same is true for any Common Security items. Any role granting unfiltered access to the Common Security item overrides any other filters on that same item.

Role A: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items. Also, a filter has been placed on part 1 of the "Account Key Security" and a filter on the Org. Key of the GLK_KEY_MSTR table.
Role B: Grants full access to the "Account Key Security" Common Security item with a filter on part 1 of the "Account Key Security" but all access with no filter on the GLK_KEY_MSTR table.

Common Security Gap

Common Security provides a convenient method of applying security on commonly used data without visiting security on every single table that it might reference. However, a single missing Common Security access can restrict any access to the table. The following two examples will demonstrate how access to a particular table such as the GLBA_BUDACT_MSTR not only requires access to the table, but to the Common Security items the table is linked to as well. The first example will demonstrate the gap in security and the second one will demonstrate a solution to that problem.

Role A: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items. Also, a filter has been placed on part 1 of the "Account Key Security" and unfiltered access to the GLBA_BUDACT_MSTR.
Role B: Grants full access to the "Account Key Security" Common Security item with a filter on part 1 of the "Account Key Security."

Correcting the Common Security Gap

To correct the gap from the previous example, either security can be applied on the Common Security item to an existing Security Role, or a new role can be added with that access granted.

Role A: Grants full access to the "Ledger Security" and "Account Key Security" Common Security items. Also, a filter has been placed on part 1 of the "Account Key Security" and unfiltered access to the GLBA_BUDACT_MSTR.
Role B: Grants full access to the "Account Key Security" Common Security item with a filter on part 1 of the "Account Key Security."
Role C: Grants full access to the "Object Code Security" Common Security item.