Security is implemented in a very basic manner in this phase of the
project. Each system user is allocated a username and password. After
logging in with this username and password, they are allocated a
their access rights to the system.
Security is checked at a number of points in the system, all related to different stages of screen display:
ModuleTreeis created, it checks which modules the user is allowed to access, and displays only those.
Please examine the relevant classes for more details regarding the workings of the security system.
Each role within the system is thus associated with security settings by providing a tuple as follows:
< ROLENAME,MODULE,TAB,ACTION >
ROLENAME is the role,
MODULE is the
module in which the
TAB resides, and
is one of
READ. If any of the other fields are specified,
READ permission is automatically assumed. The
* action is an abbreviation for all other actions. The *
character can also be used at the
MODULE level (in which
TAB must be
*), or the
level, with an intuitive meaning. Note that at the tab and module
level, the wildcard character is purely syntactic, it will
automatically generate a large number of
SecurityPermission objects representing the various
modules and tabs.
These security permissions are specified in the security package.Roles
A role is an abstract representation of a class of users. Each user entered in the system has a unique role. This role may also contain other roles. Permissions are given for the user by combining all permissions from all of the user's roles. Note that it is assumed that the role hierarchy will form a tree. If loops exist in the role graph, system behaviour is undetermined.Extensions
A number of extensions should be provided at a later stage. First, negative permissions should be added to allow for a more concise permission language.
A later version of the system will allow for fine grained field level checking of security permissions. Finally, the login system should be modified to utilize JAAS at a later stage.