(Click on images for higher definition view)
Access to all the resources on the cosbatch Servers is controlled in accordance with the organization's security policy by means of the access control objects. cosbatch v3.1 uses authorization lists. Authorization lists are maintained for all objects of the types "queue", "processor", "suite" and "event". A database table records a 4-part key: (object-type object-name,authorized-role,authorized-user) that allows authorization to be granted to individual users as well as to roles.
The new access security check ensures that the creator of an object of each of these object types ("queue", "processor", "suite" and "event") will always be granted access. When an object is added, the initial authorization list may either be empty (restricting access only to the creator of the new object), or contain the creator's role, or allow open access. There is a tri-state system property (none, all, role) to allow this policy to be specified; with the default being "all" (i.e. open-access). The authorization list for an object may only be updated by an object's owner or by a user with the "super" capability.
All static access routes within cosbatch, mainly menus and the functionality to which they give access, are associated with interface capabilities which are then assigned to roles. A user must be a member of a role that has that interface capability associated with it to perform a particular function. In this way, access to any function within cosbatch can be protected, which helps towards legislative compliance, as do the logs and audit trails generated.
The aim is to be able to offer menu options to those users who are allowed to use them, and ‘grey them out’ when users are not permitted to use them.