THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT 7.1 and later

DISCUSSION

EFT Workspaces provides a stellar solution to problem of allowing employees to share working folders with internal colleagues and external partners, leveraging the data room concept within the EFT framework to allow for project collaboration, digital materials distribution, and more. The goal of this article is to provide guidance on establishing proper license management, security, control over who can create workspaces, and meeting these goals without the need for administrators to manually create all user accounts for third parties to participate.

For new EFT implementations, there are no legacy configurations to consider, which simplifies the introduction of the Workspaces capabilities to employees and partners alike. However, when an implementation already exists and is well-known, there may be many considerations to take into account, and those will likely differ from one scenario to the next.

With that in mind, the broadest recommendation is that there be an additional site created, using the internally managed Globalscape EFT user provider (known as a “GS site”), and that site should be dedicated exclusively to Workspaces.

Rationale:

The foundational premise of the Workspaces functionality is to provide a way for new or existing EFT customers to provide working folders for collaboration. The nuances may differ based on use case, from an project manager employee uploading a project folder to EFT and sharing it out amongst colleagues and third parties participating in the project for ongoing collaboration on project data through file transfers to and from EFT, to a Channel Sales Manager uploading various pieces of marketing material and selling guides and sharing them out in a read-only manner to interested parties at new or prospective partner organizations, to Enterprise Sales Managers creating a workspace for each opportunity and inviting relevant internal and third party personnel to be able to add new RFI revisions, retrieve updated quotes, and so on. The possibilities are vast.

Implementation Details:

• Workspaces must be disabled on any other sites (unless enabled on an AD/LDAP site for exclusively internal use, but this will count against Workspaces licenses).
• Administrators must preemptively create the user accounts for internal employees they wish to allow to create workspaces and invite new users to participate.
• In the Workspaces configuration tab, allowing invitations to new users must be enabled.
• Accounts created manually for employees should be placed in a separate, non-default Settings Template (perhaps called “Employees” for example).
• Administrators will likely want to disable the “Grant full permissions to users in their home folder” setting that is enabled by default (see item C-iv below), instead explicitly checking the box to enable this option during creation of employee accounts.

Key Items of Note:

1. Administrators are not able to control who may create workspaces.
2. Workspace participation and invitation may only occur within the site where the workspace was created.
   • EXAMPLE: An employee in an LDAP site is not able to invite a third party in a GS site to participate in a workspace, regardless of whether that 3rd party already has an account in the GS site or would need to have one created for them by virtue of accepting a workspace invite.
3. Accounts created by virtue of a workspace invite:
   1. are themselves able to create and manage their own workspaces, which counts against licensing.
   2. can only invite other existing users to participate, not net new users, in order to maintain a more secure implementation.
   3. will be added to whichever Settings Template is set as the default.
   4. are treated as fully fledged users with the exception of item ii (cannot invite net new users)
   • EXAMPLE: A real home folder will be created for the user, and if default options are selected then they will have full access in that folder to do with as they please. Quotas cannot be reliably leveraged to rein this in (see item D below).
4. The contents of any workspaces in which a user participates in any role count against that user’s disk quota.
5. All other items required for EFT site operation must be acquired or otherwise accounted for, such as:
   1. Internal IP address for EFT
   2. DMZ IP address for the DMZ Gateway
   3. External IP address for incoming connections from the internet
   4. A DNS entry to provide a host name for users
      • External DNS published to resolve to the external IP address
      • Internal DNS published to resolve to the internal IP address
   5. SSL certificate purchased for that DNS entry
   6. NAT/Firewall rules added to allow for communications at the various levels of the network
      • No whitelisting is possible or recommended, as legitimate connections may come from anywhere in the world.
   7. DMZ Gateway profile created
   8. Storage provided for this separate Workspaces site
   9. Password complexity, inactive user removal, and other such policies
   10. EFT administration delegated to the appropriate parties at the appropriate level of access
   11. Incoming connection handling rules added to the load balancer (if applicable)
   12. CIC integration rules added for AV/DLP scanning of files (if applicable)
   13. Service/Port monitoring rules added (if applicable)