Role Based Security (RBS)

This release of Appx includes a new method of managing security, known as 'Role Based Security'.

Overview:

The new Role Based Security (RBS) will provide an alternative to the existing APPX Security Profiles feature. The resulting run-time security provided by RBS will be similar in function to the run-time security capabilities provided by the existing APPX Security Profiles feature but will be much easier to manage.

It is referred to as 'Role Based Security' because the security can be managed by a job function, rather than by individual users. There is a 5 level hierarchy that allows you to define the job functions in your company:

Each user in the system must be assigned to a Database/Department/Workgroup and Role. Security is then managed by the Database/Department/Workgroup/Role and User. When checking security, the system first looks for permissions at the Role/User level. If nothing is found, it then checks the Role, then the Workgroup, Department and finally Database. This means it is not necessary to establish permissions at each level. For example, if there are processes that everyone is allowed to run, then setting permission at the database level will be sufficient for everyone. This approach also makes it easier to change a users permissions, for example, if an employee is temporarily filling in for someone else, all you have to do is change their role (or add them to the same role as the other employee). You can then remove them from the role or change their role back when the original employee returns.

RBS also has an optional 'Inactivity' setting you can use to automatically prevent logins after a certain period of time. For example, you could set this to 30, and anyone who has not logged in during the last 30 days will not be allowed access.

Another optional feature is a 'Timeout' setting, where the user will be logged off after X minutes of inactivity.

Both of those settings can be set at the Database, Department, Workgroup, Role and User level. Lower levels take priority over higher levels, so a setting at the User level overrides all other levels.

RBS allows you to control execution of processes by the parent/child process combination. In other words, a user might be able to run 'Customer File Maintenance' from the 'File Maintenance' menu, but not from the Order Entry screen. This is managed by 'Access Control Lists' which will define which users are allowed to access various application objects at run-time and with which permissions.

A Parameter file sets default actions and other features of RBS.

RBS is accessed from the 'System Administration' menu.

NOTE: Role Based Security is NOT enforced when running processes directly via Option 99 from within Application Design.

Getting Started

1. Define your Databases, Departments, Workgroups, Roles, Users
2. Create Access Control List
3. Set Process Security
4. Set File/Field Security
5. Setting RBS Configuration

Reference

Managing Security

1. Security Configuration
2. Security Hierarchy Maintenance
3. Access Control List - Processes
4. Access Control List - Files/Fields

1. Security Hierarchy List/Export
2. Users
3. Inactivity Report
4. User Security Overrides
5. Locked Users
6. New/Changed Objects
7. User Rights

1. Create Access Control List
2. Export Hierarchy
3. Import Hierarchy
4. Copy Security
5. User Last Login Date/Time

Comments:

Read what other users have said about this page or add your own comments.

-- JeanNeron - 2012-10-30