Concept Topic articles provide insight into Users, Accounts, and Organizations. To review, SSProtect use is uniquely defined by your Account, and you identify yourself to this Account with your Username, which is an email account over which you have control. Accounts can run stand-alone, as Individual Accounts, or can belong to an Organization. Organizations are managed by a single Administrator and one or more assigned Delegates. These Privileged Users can control Account configuration, active components, policies, and other operational features:
- Use of SSProtect is identified by a unique Account you Login to
- You create your Account the first time you run the software
- Account Usernames utilize the address of a working email account
- An Account can be a member of an Organization, or an Individual Account
- Organizations logically group Accounts, often defined by teams in a Company
- Administrators and Delegates manage Organizations and their Accounts
- Administrators and Delegates can create Accounts, generating Registration Email
- Accounts in the same Organization can by default securely share protected content
The remainder of this article describes Trust relationships, Server Sets, and Profiles.
Zero-Config Secure Sharing
:Collaborate is the SSProtect component responsible for managing Trust relationships. It is always enabled, for every Account, and an integral part of the system.
:Collaborate provides for secure data sharing when two Accounts have a Trust relationship. All members of a single Organization, by default and at all times, trust one another. This allows all Organization members to share protected content without additional configuration. Accounts outside of an Organization cannot access protected content without being given specific permission (see below). As a result, companies often choose to deploy multiple SSProtect Organizations representing teams of users that work together while at the same time isolating and controlling the exchange of information between teams. This is done by creating and managing Third Party Trusts.
Secure Sharing with Third Party Trusts
Accounts from two different Organizations can only share data when configured as Third Party Trusts. This is a one-way association that allows a single Organization to extend secure data sharing access to a single external Account. This can be setup, "the other way" by the remote Administrator to create a bi-directional data sharing arrangement.
Third Party Trusts are compatible with both Organization and Individual Accounts. Each association can be temporarily disabled or revoked at any time, and the impact is immediate. For more information, see Protected Data Sharing and Managing Third-Party Trusts.
KODiAC Cloud Server Sets
A Server, in the SSProtect sense, is a collection of cloud server resources that host KODiAC Cloud Services to respond to requests from individual SSProtect-enabled host computers. This is better described in the article, System Overview.
Servers are deployed in highly-available clusters, then geographically distributed to make sure you and your peers have access to information at all times. These Server Sets are typically referred to with one single name, which follows the DNS infrastructure used to support deployments.
Server details are rarely important unless you plan to manage your own KODiAC Cloud Service deployment, making you the governing Service Provider. Data is not currently shared between Server Sets, and thus any self-managed deployment of KODiAC will not (yet) be able to share data with the general set of server clusters used in most every other case. The default DefiniSec Server Set association uses the DNS name ssp.secdefini.com (along with ssp-a and ssp-b hostnames). Do not change these default associations unless you are hosting your own KODiAC Cloud Services.
Email Addresses and SSProtect Identity
A single Server Set manages multiple Organizations, each containing a unique set of Accounts and thus a unique set of Usernames. Usernames are unique within and across Organizations (for a given Server Set). This is easily achieved by using email account associations for each User (and thus each Account). This serves as the User's SSProtect Identity.
Multiple Account Use
You can only use a single email address with multiple Accounts when each matching Identity (email address) is associated with a different Server Set. This is the case if you are using SSProtect in a production capacity and also engaged in Beta testing for newer release versions, since the Beta program uses a different Server Set (configured as stag.secdefini.com, along with stag-a and stag-b hostnames, whose access and visibility remains strongly protected).
CAUTION: We do NOT recommend using the same email address for multiple Accounts, except by advanced users very familiar with system use. This can be quite confusing when, for example, using :Email and trying to determine why a particular incoming protected message can't be opened. In such cases, it often comes down to the context the managing Account is using - and when incoming data is from an Account associated with a different Server Set, expectation won't align with reality.
To simplify Login, we have created Profiles to represent the combination of Username (email address), Account, Organization, and Server Set. This is a unique combination which is more easily referred to by a single moniker, i.e., "Work" or, "Home". You can gain more insight into how Profiles work by following the procedure outlined in the article, Registering a 2nd Profile.
This article was updated w/ v8.5.1 of the :Foundation Client