How Permissions Work

www.altova.com Print this Topic Previous Page Up One Level Next page

Home >  Managing User Access > Permissions and Containers >

How Permissions Work

Permissions control user access to containers. Like privileges, permissions can be granted both to users and to roles. Therefore, if a user is a part of a role, any permissions granted to the role will automatically apply to the user as well.

 

By default, permissions set on a container are inherited from the parent container. For example, let's assume that container A has a child container B. Users who have permission to access container A will have by default permission to access container B as well. However, an administrator can redefine the permissions of any user or role at every level of the container hierarchy.

 

FlowForce checks container permissions when users interact with containers. For example, users can view or change the contents of a container only if they have been granted the required permissions. Permissions are not evaluated upon job execution, therefore any permission changes will not apply retroactively to existing jobs.

 

For each FlowForce Server container, you can set the following permission types.

 

Container

The "Container" permissions define what users can do with objects in the current container.

 

Inherit

Provides to the user the same access rights to this container as those defined on the parent container.

Read

Grants the user rights to list the contents of the container.

Read, Write

Grants the user rights to list the contents of the container and to create or delete objects in the container.

 

Note: To successfully create a new configuration object, or delete an existing one, users must be granted both the Container - Read, Write permission and the Configuration - Read, Write permission.

No access

Denies the user the right to enter the container (more specifically, the container appears to the user as disabled).

 

Configuration

The "Configuration" permissions define what a user can do with configuration objects (namely, jobs and credentials) in the current container.

 

Inherit

Provides to the user the same configuration object–related rights as those defined on the parent container.

Read

Grants the user rights to view details about configuration objects within the container (such as the execution steps or triggers of a job).

Read, Write

Grants the user rights to modify any configuration object within the container (for example, edit the trigger of a job).

 

Note: To successfully create a new configuration object, or delete an existing one, users must be granted both the Container - Read, Write permission and the Configuration - Read, Write permission.

No access

Denies the user the right to view the details of any configuration objects within the container (more specifically, configuration objects appear to the user as disabled).

 

Credential

This permission defines what a user can do with credentials defined in this container.

 

Inherit

Provides to the user the same credential–related rights as those defined on the parent container.

Use

Grants the user rights to reuse any credentials defined in this container.

No access

Denies the user the right to reuse credentials defined in this container.

 

Queue

This permission defines what a user can do with queues defined in this container.

 

Inherit

Provides to the user the same queue rights as those defined on the parent container.

Use

Grants the user rights to assign a job to any queue defined in this container.

No access

Denies the user the right to assign a job to queues defined in this container.

 

Service

The "Service" permission defines access to a job exposed as a Web service, via the HTTP request interface. In addition, if a job exposes an AS2 service, then this permission controls access to the AS2 service exposed by the job, see Receiving AS2 Messages.

 

Inherit

Provides to the user the same service–related rights as those defined on the parent container.

Use

Grants the user rights to access the service and thus execute the job via the request interface.

 

Notes

Service permission checks skip any container hierarchy checks. Therefore, if granted Use permission, users may use the service without having Read access to the container in which the corresponding job is defined.
If you grant Use permission to user useranonymous, the service becomes publicly available and does not require authentication.

No access

Denies the user the right to access the job as a Web service.

 

Function

In addition to jobs, credentials, and other configuration data, a container may contain functions. These include built-in FlowForce functions, RaptorXML functions, and MapForce mappings or StyleVision transformations deployed to FlowForce.

 

When a FlowForce user creates a job, some execution step in their job may refer to functions from the same container, or from a different one. The "Function" permission defines whether users can invoke (refer to) functions from the container where the permission is defined.

 

For example, let's assume that an administrator has deployed various MapForce mappings to a FlowForce container called "Restricted". The administrator can then decide if users should be able to refer to functions in this container, by changing the "Function" permission. More specifically, any user or role who has the Function - Use permission on container "Restricted" can refer to functions from this container (i.e., select them from a drop-down list when they create an execution step). On the contrary, users or roles with the Function - No Access permission will not be able to select any function from the "Restricted" container.

 

If an administrator revokes users' access to functions after they had already used the function in a job, those users won't be able to run the job any longer. The job configuration page displays in this case a message with the text "You don't have permission to use the selected function".

 

Inherit

Provides to the user the same function–related rights as those defined on the parent container.

Use

Grants the user rights to call (refer to) any function defined inside the container.

No access

Denies the user rights to call (refer to) any function defined inside the container.

 

 

Certificate

This permission defines how a user can access a digital security certificate from the current container. For more information, see Configuring AS2 Certificates.

 

Inherit

Provides to the user the same rights as those defined on the parent container.

Use

Grants the user rights to use (refer to) any certificate defined inside the container.

No access

Denies the user rights to use (refer to) any certificate defined inside the container.

 

AS2 Partner

This permission defines how a user can access AS2 partner objects defined in the current container. For more information, see Configuring AS2 Partners.

 

Inherit

Provides to the user the same rights as those defined on the parent container.

Use

Grants the user rights to use (refer to) any AS2 partner object defined inside the container.

No access

Denies the user rights to use (refer to) any AS2 partner object defined inside the container.

 

 

Security

The security permission controls access to permissions of any child containers defined in the current container.

 

By default, users are permitted to read only permissions applicable to them (that is, any permissions assigned to themselves or any role they are a member of). However, users who have the Read users and roles privilege can read all permission entries.

 

Inherit

Provides to the user the same security–related rights as those defined on the parent container.

Read Security

Grants the user rights to view the permissions of any child of the container.

Read and Write Security

Grants the user rights to change the permissions of any child of the container.

No access

Denies the user rights to view the permissions of any child of the container.


© 2019 Altova GmbH