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 an Organization and three 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.
This Walkthrough is most effective when you've first worked through the previous Walkthrough, Peer Data Sharing, and its' prerequisites. Further, complex topics use specific state and configuration details that may be more difficult to track if attempted independently or out of the presented/ recommended order. Refer back to the Introduction and Preparation for details.
NOTE: We abbreviate references to activities covered in previous Walkthroughs. Though it may be not be too difficult to figure out the required steps on the fly, results will depend on your prior experience.
Create a New Organization
Third Party Trusts create sharing permissions for Accounts to access content Owned by those in other Organizations.* As such, we will need to create an additional Organization as the participating Third Party.
We will do this with a Sign-Up operation that specifies an Organization rather than first create an Individual Account then Migrate as described in two Walkthroughs, Introduction and Preparation and Migrate to an Organization.
* Data Owners, Qualified Instances, Version Instances, and Version Chains are described in the Walkthrough, :Recover w/ Shared Content.
STEP 1: Refresh Login to view the Login dialog, then from Profiles choose Create New.... We recommend the use of a gmail alias and, consistent with existing Walkthroughs, use for our purposes the Organization named gmail-definisec_t2 with the email alias email@example.com as shown below:
STEP 2: Match the Email Address with your gmail alias (or other email address) and suitably-aligned auto-approval Organization Name with both Org and :Recover checked, then choose Create. This will be your 2nd Organization's Administrator.
STEP 3: When prompted to set your Default Folder, choose Yes then create and use C:\TestData2. When prompted to Export Keys, choose Yes and follow the procedure as before. You will be returned to the Login dialog to continue - enter your new Account's Password to complete the operation and Login to the new context.
STEP 4: While actively Logged in to the new Account, create a text file, C:\TestData2\Sample2.txt and include the identifying text, V1 Test2Admin then save/ close. Protect the resulting file to complete the foundation we'll use.
Rename Profiles to Align Ongoing Proceedings
We can use Profiles for a level of indirection in subsequent text, eliminating the need to constantly qualify which Organization/ Account we're using and refer simply to the Profile name.
STEP 4: Refresh Login and choose Advanced from the Login dialog:
STEP 5: Choose Profiles to edit your existing Profiles:
For each Profile, Edit... then enter the New Name to match the list below (or similar), then Save. Use Done when finished, which returns you to the main Login dialog.
Despite the lack of creativity, we'll use the following references going forward:
- Organization 1 Administrator -> firstname.lastname@example.org -> Org1_Admin
- Organization 1 User 1 -> email@example.com -> Org1_User1
- Organization 1 User 3 -> firstname.lastname@example.org -> Org1_User3
- Organization 2 Administrator -> email@example.com -> Org2_Admin
Note that the default Profile naming convention is different - <Organization Name> (<email_address>), though for our purposes we're using the modified convention specifically to mask the need to qualify each reference.
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 6: Login to Org1_User1 then double-click the file, C:\TestData2\Sample2.txt. This operation will fail: Org 2 has not (yet) granted external access.
This results in the following notification:
At the same time, SSProtect purposely blocks the requesting application from reading raw ciphertext, forcing an error. This can, at times, be disconcerting depending on how the application reports the error. Notepad (suitably) reports a permission error:
STEP 7: In the same Org1_User1 context, use the Quick Action menu to acquire a File Sequence Report, which should include the following:
STEP 8: 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. Compare these results with the Walkthrough, Peer Data Sharing, and you'll notice a difference in the Detail: This activity reports, Shared by... whereas Peer Sharing activity uses the text, Managed by.... This case, using the former reference, indicates that a Third Party Trust association governs access, meaning the caller and Data Owner aren't in the same Organization (denoted to be gmail-definisec_t2 as expected).
Add/ Utilize a Third Party Trust Association
Let's configure the proper Third Party Trust association and repeat the previous Shared Access operation.
STEP 9: Refresh Login to switch context back to Org2_Admin.
STEP 10: 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 11: Click Invite... then in the popup, shown below, enter the Email Address of the intended Third Party Trust - in our case, firstname.lastname@example.org:
STEP 12: 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 13: 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 14: 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:
Again, note the difference between the, Shared by... reference in the, Shared Decrypt (Opt) activity Detail and the, Managed by... from related Peer Sharing activities. 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 15: Refresh Login and return to the Org2_Admin context.
STEP 16: Navigate to Sharing Policy, the dialog displayed above.
STEP 17: 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 email@example.com, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client