Access to workflow platforms Control Sand, Shenzhen Yi Sibo Access control technology has penetrated into various industries in contemporary society, and many international high-tech companies have implemented access control technology in their own products. Related, such as enterprise-level relational database vendors Oracle and IBM, have their own access control technology.
Taking IBM's DB2 products as an example, there are two concepts that have permissions and privileges: permissions are composed of privilege groups and higher-level database managers (instance levels); while privileges are for databases and objects. Operation is performed. At the same time, DB2 also defines five permissions, where sysadm, sysctrl, and sysmaint are system instance level privileges, while DBADM and LOAD permissions are specified for a particular database to a user or group. For database-level privileges and object-level privileges, the former's scope covers all objects in the database, while the latter is only related to a particular object. This assignment of this permission and privilege make the database managers and users can perform licensed resource operations in accordance with the access control policies set and configured in DB2, can be used as the basic standards in the implementation of access control technology.
Based on these basic criteria, we are not difficult to provide an access control module for our application system. Here we take a workflow system as an example to provide access control technology related implementation. In practical applications, the workflow system is usually provided to commercial users with a general platform that needs to perform secondary development, which determines the permission control and general database rights control implementation of the workflow system. Slightly different. In addition to the permissions and operation of the workflow system, it is also necessary to accommodate the service level authority and operation of the secondary development user.
According to the above requirements, we can give the following composition elements: personnel, organization, role, system-level operation and business level operation, the relationship class diagram is as follows, in order to maintain a simple, this type of map structure is not optimized.
Figure 1: Access control module Basic relationship class diagram
For system-level operations, it is mainly for the operation of the entire workflow system. We can assume that one manager is specified in the initial phase of the system, with all system-level operations, these operations are given to a role called Admin In. The list is as follows:
Operating code
Operating name
Description
0001
Create_wf_model
Create a workflow template
0002
Update_wf_model
Update workflow template
0003
DELETE_WF_MODEL
Delete Workflow Template
0004
LOAD_WF_MODEL
Loading workflow template
0005 0005
Unload_wf_model
Uninstall workflow template
0006
START_WF
Start workflow
0007
STOP_WF
Terminate workflow (unconditional completely terminated)
0008
Suspend_wf
Hang up workflow
0009
Resume_wf
Restore workflow
0010
Grant_sys_oper
Give role system level operation capability
0011
REVOKE_SYS_OPER
Remove role system level operation capability
0012
Grant_buss_oper
Give role business grade operation capability
0013
REVOKE_BUSS_OPER
Remove role business grade operational capabilities
The above list is just a subset, new, delete, modify user, working group, and role of a system-level operation, not included, and different workflow system developers can define Other different system-level operations. We specify that the operating code starting with 0 represents system-level operations, which can exist on the system database table or on other persistent storage media.
Here, we set a simple secondary development business environment: handling customer demolition flow. The following is a simplified processing process:
Figure 2: Handling customer demolition process According to the business process given above, we can develop two or three roles, taking two roles as an example: employee and manager. However, there are three business-level operations in this business application, assigned to the corresponding roles, and then specify the user defined in the system, and the specific definition is as follows:
Operating code
Operating name
Description
Located
1001
Complain_Handle
Demolition for customers
Employee, manager
1002
Complain_Confirm
Confirm for customer demolition processing
manager
1003
Complain_file
Demolize and process information archive
Employee, manager
After specifying these operations, the workflow system will save this part of the information to the system database table, the system administrator will specify an executor role when modeling the workflow, specifies an executor role, the login is The allocated role will be used by the workflow engine to determine if the user can process the task.
At this point, we basically completed an access control design on the general workflow system and assumes a business use case for secondary development on the platform. There are many specific schemes to achieve this preliminary design and can be optimized. After all, in this simple example, there is still too many details, please welcome everyone to discuss, please indicate the source, thank you!
