Altova FlowForce Server 2024 Advanced Edition

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 userroot has this privilege.

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 userroot has this privilege.

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 userroot has this privilege.

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 userroot has this privilege. This privilege should normally be reserved to userroot only, unless you have a good reason to do otherwise.

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 role authenticated role, and hence every user account except useranonymous, has this privilege.

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 userroot has this privilege.

 

Inheritance

You can assign privileges either directly to a user (for example, to userAlethia Alonso) , or to a particular role (for example, to role 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 role Employees and a role called role Marketing Department. Then you can assign the role role Marketing Department to be a member of role Employees. This means that all privileges and permissions granted to role Employees will be automatically inherited by users who are members of role Marketing Department.

 

Furthermore, you can assign the role Marketing Manager role to be a member of role Marketing Department role. In this case, the role Marketing Manager role will inherit privileges both from the roleMarketing Department and from the role Employees roles. When a new marketing manager joins your organization, userAlethia Alonso, if she is assigned the role Marketing Manager role, she will inherit all other privileges from the broader roles.

 

RoleHierarchyDiagram

 

As the diagram shows, userAlethia Alonso inherits permissions and privileges from the role role Marketing Manager. This role, in its turn, inherits privileges from the role 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.

 

UserRoles2

 

As the diagram shows, every user in the system inherits the privileges defined in the role all role. However, only existing users (in this case, user root) inherit the privileges defined in the role authenticated role. If you add any new users to FlowForce Server, they are automatically assigned to the role all and role authenticated role (and thus granted the privileges defined in those roles, if any), as follows.

 

UserRoles3

 

 

See also

Default Users and Roles

Viewing Privilege Reports

© 2017-2023 Altova GmbH