This article introduces you to Third Party Trust operation that extends the previous Peer Data Sharing Walkthrough.
The previous Walkthrough Sections, Common Tasks and Simple Administration, showed you how to create two Organizations and four associated Accounts while working through basic end-user and administrative tasks.
The first Walkthrough in this section, Peer Data Sharing, introduced you to Zero-Configuration Data Sharing for Organization Peers. This article continues and introduces Third Party Trusts.
IMPORTANT: Keep in mind that SSProtect/ KODiAC do not provide content to Accounts or other resources except when Restoring data, which is explicitly covered in the Walkthrough, :Recover w/ Shared Content. Sharing Policy as a result doesn't expose content, it only serves to grant access to content delivered by some other means.
This Walkthrough is most effective when you've first worked through the previous Walkthrough, Peer Data Sharing, and its' prerequisites. This Walkthrough uses specific state and configuration details that may be difficult to track if attempted independently. Refer back to the Introduction and Preparation for details.
As such, for this specific Walkthrough, we do not recommend proceeding without previous work to align Account configuration and Profile names as specifically laid out in the Walkthrough, Default Folders, Sign-Up, Profiles.
Create Data To Test Third Party Trust Sharing
Before we proceed, let's create a test file owned by the second Organization's Administrator. We'll need this to carry out activities around Third Party Trust Sharing.
STEP 1: Refresh Login and choose Org2_Admin from the Profile dropdown, enter the Password, and Login.
STEP 2: Create a text file, C:\TestData2\Sample2.txt, and include the identifying text, V1 Test2Admin then Save/ Close.
STEP 3: From File Explorer, right-click C:\TestData2\Sample2.txt and choose SSProtect Activate to protect it.
Failed Third Party Access Attempt
Let's take a look at a failed attempt to access Third Party content to see how activity is Audited/ Reported.
STEP 4: Refresh Login and choose Org1_User1 to establish a Login Session - enter the associated Account Password then Login.
STEP 5: From File Explorer, double-click the file, C:\TestData2\Sample2.txt. This operation will fail: Org 2 has not (yet) granted sharing rights to Org1_User1:
At the same time, SSProtect purposely blocks the requesting application from reading raw ciphertext, which forces an error. This can, at times, be disconcerting depending on how the application reports the problem. Notepad (suitably) reports a permission error:
STEP 6: In the same Org1_User1 context, use the Quick Action menu to acquire a File Sequence Report, which should include the following:
STEP 7: In the same Org1_User1 context, use the Quick Action menu to acquire a File Detail Report, which should include the following:
If you were to acquire the same two Reports from the owner's context, Org2_Admin, you'd see the same entries, with both Reports identifying the failed attempt.
Notice that the Detail is suppressed. This avoids an Information Disclosure Vulnerability, further explained in STEP 13, below.
Add/ Utilize a Third Party Trust Association
Let's configure the proper Third Party Trust association and repeat the previous Shared Access operation.
STEP 8: Refresh Login to switch context back to Org2_Admin.
STEP 9: From the context menu, choose Sharing Policy then the submenu Manage:
This dialog is further described in the article, Managing Third Party Trusts, though in summary:
- All Organization Users can view Policy, though only Privileged Users can make changes
- Changes to Trust associations utilize Email Notification to inform affected parties
- The first time a Trust is created, the Trustee must Refresh Login before shared access is fully functional
- With the exception of first-time Refresh Login, changes apply to subsequent requests by affected Users
- Once a Trust is configured, you can dynamically Enable/ Disable access using the associated buttons
Finally, Validate, for the purposes of this discussion, is not relevant. It is seldom necessary and almost always carried out as part of Invite... activity. Other than very low-level fundamentals, it is not related to New Account Validation as there is no temporary credential to risk while forming the Trust relationship. Validate is as a result only present when the uncommon circumstances present that require the manual, secondary action that completes the Invite... Trust association.
STEP 10: Click Invite... then in the popup, shown below, enter the Email Address of the intended Third Party Trust - in our case, email@example.com:
STEP 11: Choose OK to submit the request. If you are prompted with notification that the request could not be Validated, click the Validate button to complete the transaction (and acknowledge the resulting status notification).
You should as a result see the following in your Sharing Policy display:
STEP 12: Refresh Login and return to the context of Org1_User1, then double-click C:\TestData2\Sample2.txt in File Explorer, performing a shared Managed Open operation to access content. Because you performed Login after the Trust was submitted, the operation will have the required fundamentals to succeed. Add the common identifying text we've been using - V2 Org1User1 - then save/ close. The resulting re-encrypted file will carry the Yellow Overlay Icon in File Explorer.
STEP 13: Acquire the File Sequence/ File Detail Reports to compare the prior, failed attempt with the most recent successful access activities.
Your File Sequence Report should include the following failure/ success entries shown in the following abbreviated form, which also removes intermediate entries:
Your File Detail Report should include the following failure/ success entries show in the following abbreviated form, which also removes intermediate entries:
Compare these results with the Walkthrough, Peer Data Sharing, and you'll notice a difference in the Detail: This report's Shared Decrypt (Opt) Detail shows, Shared by... whereas the Peer Sharing activity Detail uses the text, Managed by....
The difference is critical: Managed by... represents the built-in/ inherent Organization Peer trust that always exists for all members of the same Organization. Shared by... represents a Third Party Trust Policy that has been specifically configured, which can also be Enabled/ Disabled on the fly. The Detail is not shown if the Third Party Trust relationship does not exist at the time (as shown), however will appear when the Third Party Trust is configured but Disabled (a case not shown here, which would be called out in the Result).
As expected, if you request the same reports as Org2_Admin, you will find the same entries.
Dynamically Disable Third Party Trust Permissions
You can Disable/ Enable individual Third Party Trust associations from the Sharing Policy dialog we used before.
STEP 14: Refresh Login and return to the Org2_Admin context.
STEP 15: Navigate to Sharing Policy, the dialog displayed above.
STEP 16: Choose the Trust you defined in previous steps, then click Disable. The button will switch state to Enable for you to re-enable when you are ready.
You can Refresh Login and attempt to access shared materials to verify that you will not be permitted, then return and re-enable the Trust using the same procedure above. It's worth working through these steps and verifying the associated Usage Report output since it provides independent control and auditing for related dynamics.
Looking Deeper: One-Way Third Party Trusts
Third Party Trust Associations are one-way: In our proceedings, Org2_Admin trusts Org1_User1, which means Org1_User1 would be able to access any content from any Org2 User. However, Org2 Users cannot access Org1_User1 content. Why, then, can Org2_Admin access changes Org1_User1 made?
This isn't based on any Trust Association, it's because, in the given case, Org2_Admin is the Data Owner. As a result, not only can Org2_Admin access changes made by Org1_User1, but any Org2 User would be able to access those changes. However...
Looking Deeper: Trusts Are Not Transitive
Trust relationships are not transitive, in that you cannot inherit access to content as a result of Trusts with the same entity.
For example, in the above scenario, we've used the following relationships:
- Org2_Admin -> Trusts Org1_User1 (with a Third Party Trust association)
- Org1_User1 -> Entertains inherent Organization Peer Trust with Org1_User2 (and also Org1_Admin)
You have all the tools necessary to verify the following:
- Org2_Admin -> Sends Managed Content V1 to Org1_User1
- Org1_User1 -> Securely accesses content, making changes to create V2 (using the Third Party Trust)
- Org1_User1 -> Sends the resulting V2 to Org1_User2
- Org1_User2 -> Will NOT be able to access either V1 or V2 of the Managed Content
Org1_User2 can only access content if and when Org2_Admin - or some other Privileged User in the Org2 SSProtect Organization, explicitly adds Org1_User2 as a Third Party Trust. Note however that the file's presence and stored accessibility can of course precede the Trust association: Once the Trust is made and Org1_User2 performs Refresh Login, subsequent access will succeed (unless of course not Validated or if Disabled).
:Collaborate's Policy-based Data Sharing facilitates end-user ease-of-use and places controls in the hands of those directly responsible for defining and managing Sharing Policy. This facilitates dynamic changes, freeing end-users from the worries specific to defining and managing recipients and groups while empowering independent Teams to define their own Trust associations. By combining automatic Organization Peer Trusts and managed Third Party Trusts, associated tasks and controls are isolated to manageable steps that can be appropriately managed when executing audits and reviews driven by regulatory controls.
Organization Peer Sharing is the foundation for Zero-Configuration Collaboration, which automates the process to help define logical boundaries when grouping Accounts together in Organizations. When used together with Organization Naming conventions, companies can deploy multiple SSProtect Organizations that more closely resemble Team dynamics, creating boundaries that inhibit internal malice and/ or help track and contain insider threats.
This approach serves the primary purpose of SSProtect in extending the security of existing applications and content without adversely impacting end-user activities.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client