Workspaces Permissions

Workspaces permissions are separate from the VFS permissions, such as those permissions for the Usr folders. Users who have Workspaces permissions on a folder will not appear in the VFS permissions for that folder. For example (as shown below):

  1. "imauser2" has full permissions on the \Usr\imauser2\ folder in VFS.

  2. In Workspaces, "imauser2" has shared a folder called "folder 2" with "imauser1."

  3. When the administrator clicks "folder 2" in the Workspace Folder tree, you can see that "imauser1" has Workspaces permissions on that folder.

  4. However, only "imauser2" has VFS permissions on that folder.

Specify Custom Default Workspaces Sharing Permissions

By default, all Workspaces permissions are selected, and the user is expected to clear any permissions that you do want to give the invitee when a folder is shared. Alternatively, the EFT administrator can change the default permissions so that one or more permissions are NOT selected by default, and then the user sharing the folder has to explicitly enable the permission. Changing the defaults does NOT disable the permission; it simply is not selected by default. The sharing user can still enable it when inviting users to share a Workspace.

Workspaces Permissions on an Active Directory Site

Workspaces has the ability to invite external users on an Active Directory Site. Described below is what occurs when a non-AD account has been invited to a Workspace, what permissions the EFT Server enforces for file activity, and how that applies to the "Comments" feature of Workspaces. This is important because the basic behavior of an AD Site, independent of Workspaces, is that any client that logs in as an AD account will subsequently access all files exposed by EFT's protocol engines using that very same AD account used to log in (known as "impersonation"). Thus, it is not EFT that enforces file system permissions to local and UNC paths; it is the Windows operating system.

When EFT allows non-AD users to gain access to this Site (when we allow invitations to external parties) then we no longer impersonate an AD user and, therefore, our EFT application is limited in access by the service account under which it runs; however, this might be more permissive than the permissions for any individual user in the AD server.

For example, suppose your organization's AD users have READ/WRITE access to everything on a shared drive, and have explicit DELETE permission to our own folder but no one else's folder. Suppose the IT administrator set up a Folder Monitor rule against the shared drive. The IT administrator would have to run the EFT service as an AD account that had READ/WRITE/DELETE permissions across the whole shared drive so that the Folder Monitor workflows can move or delete files, or so that the EFTArchive operation worked, and so on.

Suddenly, there is a security concern: Any externally invited Workspace user will act against the shared drive the same as the EFT service account, not an individual AD account.

THEREFORE¸ our application itself must impose permissions checks on all file access for such accounts (which, by the way, is exactly how LDAP, Local, and ODBC authentication work).

EFT server will perform a permissions check on any assignment of Workspaces permissions to a participant (creation or modification time). EFT compares the OWNER permissions to the requested Workspaces permissions for a participant, and ensures at that moment that the OWNER does not grant MORE permission to a given folder than that which the owner of the folder holds.

All file activity within a Workspace is managed by EFT to conform to ONLY those permissions allowed by the Workspace configuration. Therefore, EFT enforces that Workspace permissions are equal to or less privileged than the owner's permissions, regardless of the service account under which EFT operates.

Below is a summary table that describes the permissions checks EFT applies to Workspace file and Comments activity for both OWNERS and for PARTICIPANTS upon adding or modifying participants in a Workspace:

Operation on file or comments

Required Owner EFT VFS permissions

Required Participant Workspace permissions
ADD PERMISSION_FILE_APPEND or PERMISSION_FILE_UPLOAD canUploadFile
UPDATE PERMISSION_FILE_APPEND or PERMISSION_FILE_UPLOAD canUploadFile
DELETE PERMISSION_FILE_APPEND or PERMISSION_FILE_UPLOAD canUploadFile
GET PERMISSION_DIR_LIST N/A – Means that Participant can read comment because Owner invited them to Workspace.

For example, for the invited user to be able to comments to files, *both* of the following conditions must be met:

  • Owner must have Append or Upload EFT VFS permission for that file.

  • Participant (invitee) must be granted the Upload Workspace permission by the inviter.