The ERROS Connectionist Database has most advanced features for controlling security for data and applications. Although primarily designed for operating ERROS applications, these features are equally suitable for improving security for existing traditional, non-ERROS, applications and for access to any OS/400 objects.
These ERROS security functions work in addition to AS/400 security.
Part of the ERROS security philosophy is that operators should not be allowed any access to an OS/400 command line, although ERROS does not prevent this. Where they need access to OS/400 commands, this can be provided through the ERROS Connectionist Database.
The ERROS Connectionist Database provides very powerful and flexibile security quite unlike that available elsewhere on the AS/400 or on any other computer platform. These may be considered under two broad headings -
ERROS security can also be used to control access to non-ERROS applications and other AS/400 objects. With relatively simple program changes, ERROS can also be used for action control for non-ERROS applications.
All ERROS applications are defined in the Connectionist Database and can only be started after starting ERROS. There is only one OS/400 initial program for starting ERROS and no additional ones for starting individual ERROS applications as authority to ERROS applications is also defined in the Connectionist Database. If traditional, non-ERROS, applications are authorised to individual operators through ERROS, the operators would all have the same initial program even though different programs may be needed to start the applications.
Since authorising an application to an operator takes only a few seconds within ERROS, it is normal for ERROS users to have their own user profile and password with each application authorised only to the appropriate operators. However, applications can also be authorised to a job function, or to a department or to a location, etc., so that all users with the job function, in the department or at the location can operate it, even though they signed on with their own user profiles.
All ERROS records are indexed using a 28 byte binary key, so no standard utilities, such as SQL, would be able to "understand" the ERROS Connectionist Database. Thus security cannot readily be bypassed. SQL is not required for operating ERROS. The security functions can also be used to determine who can change aspects of security in the database.
The rules for validating access to an object are defined in the ERROS Connectionist database. These can, if necessary, be of extraordinary complexity, yet they can be equally very simple. This flexibility does not lead to a complex learning curve for defining simple tests. Equally, the ability to define complex tests does not degrade performance when only minimal checks are required.
Whilst ERROS security was designed to control access to ERROS applications and user data in the ERROS database, they can equally be used for controlling access to other objects on the system. The rules stored in the database may be used in conjunction with user programs if required, but for ordinary business data, this would not generally be required, even if data is of a very sensitive nature where very tightly controlled security is required.
A complete audit trail to all changes in the ERROS Connectionist Database is automatically maintained and cannot be switched off. This audit trail, which includes "before" and "after" images of all records changed, will cover all changes made to security, as well as to data and application definitions and to user data. If an operator selects a record and presses the audit trail function key, ERROS will immediately display the identity of the operator who made the change, the date and time stamp, type of change, etc..
This information is available for each iteration of every attribute that makes up the "logical" record perceived by users. Thus a contact may have several telephone numbers, entered by different operators on different occasions, perhaps in different applications - each one will have its own audit trail information. Access to individual applications can be granted by creating a direct relationship between each application and each operator. Alternatively, relationships can also be created between applications and locations, departments or job functions, and operators at the location, or in the department or with the job function can inherit the access to the applications. Where there are multiple subsidiary companies in a group, the access would be limited to locations, departments and job functions in the company of which the operator is an employee. All such relationships are defined in the ERROS database. Where two companies in a group employ people with the same job function, the applications available through the job function can be defined separately for each job function for each company.
A total of 18 separate functions are defined for each operator (or location, department or job function) for each application. These include authority to access, add, change, delete, remove, navigate to related records, access lower level records in an hierarchy, copy, change identifier, etc.. The values for these functions are defined separately for each operator for each application. Thus an operator may have rights to access and change records in a particular entity type in one application yet, for the same entity type, have access only rights in a second application and in a third applicaiton have add only rights without access (he or she cannot even access the records that they have added, unless throught a different route to the data such as access only to those records that they have created).
The values for each of these functions are numeric and can range from "1" to "9. "1" is the highest value and "9" is the lowest. At present only values "5" to "9" have been implemented. A similar set of 18 separate functions is defined for each attribute for each entity type for each application. These may have numeric values in the range "0" to "9". "0" means that the function cannot be carried out by any operator under any circumstances at that point although they or another operator may be able to carry out the function in another application or even by taking another route to the data in the same application where the security allows this. For four functions - access, update, deletion (i.e. tag for deletion and hide but do not remove) and remove (actually remove from the database), higher level security may be put on individual attribute iterations. These values are deducted from the values for the attribute/entity type/application combination and the result is then compared with the operator's level of authority for the application. To be able to carry out a function, the value for the operator must be less than or equal to the value required for the function the attribute/entity type/application combination
For instance, access for a particular, perhaps unlisted, telephone number for a contact, possibly one of several for that contact, might be limited to, say, senior management.