The Imixs Workflow technology contains a multiple-level security model that offers a great space of flexibility while controlling the access to all parts of a workitem within the Imixs JEE workflow system. The highest security level is achieved by means of access roles. This is a kind of ACL (access control list) for the workitems managed through the Imixs workflow system.
You can define this individual roles to precisely control who will have access to certain workitems and which maximum privileges should be assigned to each user. See also the JEE Security Configuration. For instance, a user can be authorized for only reading workitems while another one is allowed to create and process them.
The following section describes the concept how to restrict access to workitems in the Imixs JEE workflow system using the different general access roles. The access privileges can be controlled by the deployment descriptors. See details about the deployment descriptor here.
The security concept of the Imixs JEE workflow defines 5 roles :
Each role allows the user a different privilege to work with the Imixs JEE Workflow System in general.
It is important to take care about that a user must have at least read access to a workitem if he wants to process a workitem.
The following table shows the mapping of different roles and shows what effective access a user is granted to a workitem.
|AccessLevel||read public workitems||read personal workitems||read protected workitems||write public workitems||write personal workitems||write protected workitems|
To restrict the access to workitems of the Imixs JEE workflow system follow these rules:
1. Assign the users the "ACCESSLEVEL.READER" role to grant read access.
2. Assign the users the "ACCESSLEVEL.AUTHOR" role to grant write access.
3. To grant explicit read privileges to a workitem define reader privileges.
4. To grant explicit write privileges to a workitem define author privileges.
Read access privileges assigned to a workitem define all users who have read privileges for a workitem inside the workflow system if they do not have the MANAGERACCESS.
Assigning read access privileges to a workitem, users are not able to see it and so the user can not access a workitem by the getter methods in the workflow service interface. The read access privilege is independent from the later discussed write access privilege. So you can restrict the access privileges of users who have no manager access privileges preventing them from reading documents if they are not listed in a reader field. Users who have author or editor access privileges can read a document if the following conditions are met:
Write access privileges assigned to a workitem define the write access for all users who have author privileges (AUTHORACCESS) inside the workflow system. Those users can process and remove a workitem through the methods provided by the workflow service. Even workitems the user has created can not be modified if the user is not explicit listed in the access privileges. Users who are not authorized to read a workitem will never be able to edit a workitem. This even applies if you specify write access privileges for these users. Access by users who have at least editor access privileges for the workflow system is not restricted by an author field. The write access provided for a workitem only affects users with author access privileges for the hole workflow system.
Users who have author access privileges can edit a workitem if the following conditions are met: