How Privileges Work
Privileges define what users can do in FlowForce Server (for example, set own password, read users and roles, stop any job, and so on). Privileges are different from permissions in the sense that permissions control user access to containers, whereas privileges are effective globally across FlowForce Server. The following simple rule might help you distinguish quickly between privileges and permissions: privileges are global, permissions are local.
Like permissions, privileges can be assigned both to individual users and to roles. Therefore, when users log on to FlowForce Server, their set of effective privileges is determined by:
a) the privileges they have been assigned directly
b) the privileges assigned to any roles that the user is member of.
The following privileges are available in FlowForce Server.
Define execution queues | Grants rights to create and maintain job execution queues. This includes both queues local to the job and external queues defined outside of the job. External queues are used in conjunction with distributed execution, see Distributed Execution. |
Maintain cluster | Grants rights to perform actions that let one manage multiple FlowForce Server instances as a cluster. For example, a user requires this privilege in order to be able to convert the current service instance of FlowForce Server into a "worker", see Load Balancing and Distributed Execution. |
Maintain global settings | This privilege grants rights to change the FlowForce Server global settings available in the Settings page—that is, the time zone and the mail server settings. This is an administrative privilege and should only be granted to FlowForce Server administrators. |
Maintain users, roles and privileges | This privilege grants rights to add, edit, and delete the following data:
•Users •Roles •Privileges •Passwords
This is an administrative privilege and should only be granted to FlowForce Server administrators. By default, only the user |
Override security | Users with this privilege can change container permissions without having "write" security permission. This allows FlowForce Server administrators to regain access to resources accidentally rendered inaccessible.
This is an administrative privilege and should only be assigned to FlowForce Server administrators. By default, only the user |
Read users and roles | By default, users can see only their own user account and any roles they are member of. When granted this privilege, users can see all existing users and roles.
By default, only the user |
Retrieve sensitive data | This privilege grants the right to retrieve and view the following categories of sensitive data as plain text:
•Passwords •Certificate private keys •OAuth 2.0 access tokens, refresh tokens, and client secrets.
By default, only the user |
Set own password | This privilege grants to users the right to change their own password. Users who do not have this privilege need to have their password set by a FlowForce Server administrator.
By default, the |
Stop any job | This privilege grants the right to stop any running FlowForce Server job, regardless of the user who created it. |
View unfiltered log | By default, users can see log entries related to configurations to which they have "read" access. If granted this privilege, users can read all log entries, including those not associated with a specific configuration.
By default, only the user |
Inheritance
You can assign privileges either directly to a user (for example, to 
Alethia Alonso) , or to a particular role (for example, to 
Marketing Manager). The latter approach is recommended, because it simplifies management of privileges in the long term. For example, users may switch departments, or they might join or leave your organization. In either case, maintaining privileges for each individual user may become a counter-productive task. By assigning privileges to roles rather than users, you decrease granularity, simplify maintenance, and focus on the business need of each group or department rather than on individual users.
You can model the hierarchy of your organization or business within FlowForce Server by assigning roles to other roles. For example, you can create a role called Employees and a role called Marketing Department. Then you can assign the role Marketing Department to be a member of Employees. This means that all privileges and permissions granted to Employees will be automatically inherited by users who are members of Marketing Department.
Furthermore, you can assign the Marketing Manager role to be a member of Marketing Department role. In this case, the Marketing Manager role will inherit privileges both from the Marketing Department and from the Employees roles. When a new marketing manager joins your organization, Alethia Alonso, if she is assigned the Marketing Manager role, she will inherit all other privileges from the broader roles.
As the diagram shows, Alethia Alonso inherits permissions and privileges from the role Marketing Manager. This role, in its turn, inherits privileges from the Marketing Department, and so on.
In a newly installed FlowForce Server system, considering the default users and roles, the users and privileges diagram looks as follows.
As the diagram shows, every user in the system inherits the privileges defined in the all role. However, only existing users (in this case, root) inherit the privileges defined in the authenticated role. If you add any new users to FlowForce Server, they are automatically assigned to the all and authenticated role (and thus granted the privileges defined in those roles, if any), as follows.
