Background

Synapse is a SasS application, used in a broad array of projects, each of which has stakeholders in the security of their hosted data. In a number of engagements, an external organization is concerned that their data not be exposed to workers outside of their organization. For example, Sage is contracted to support use of Synapse by Arcus Bio (AB) to host data private to their company. Today the restriction of data access would be implemented through Synapse sharing settings (ACLs): Sage would advise Arcus Bio workers not to share data with users outside of their org'. However, stakeholders at Arcus Bio can reasonably expect that Synapse can further prevent non-Arcus Bio workers to access their organization’s data even if their workers make a mistake when managing sharing settings. I.e., Sage should make it impossible for non-Arcus Bio users to access Arcus Bio data, regardless of what Arcus Bio users do.

Moreover, organizations other than Arcus Bio should has some assurance that Arcus Bio not be able to access their data. In the Arcus Bio contract, Sage has agreed that Arcus Bio workers will create Synapse accounts and authenticate to Synapse using the Arcus Bio identity provider (IdP). [Such requests have arisen multiple times over the years, e.g., from Genentech and ADDI. The rationale – if not stated explicitly by the customer -- is that using a corporate IdP ensures that off-boarding workers from the organization is reliable: When the user is removed from the central IdP they lose access to all resources controlled by that IdP. Sage seeks similar benefits by using JumpCloud.]. When Synapse admits an IdP it delegates control of any and all accounts linked to that IdP: If the IdP were compromised, someone might have access to a set of Synapse accounts, along with all resources those accounts could access. So non-Arcus Bio users should have some assurance that their data cannot be shared with any Arcus Bio users, thus mitigating the risk of a compromise of the A.B. IdP.

In cybersecurity, isolating enterprises is done by using security realms. Oracle defines a realm in this way:

The protected resources on a server can be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database containing a collection of users and groups. For a web application, a realm is a complete database of users and groups identified as valid users of a web application or a set of web applications and controlled by the same authentication policy.

One approach to creating multiple realms is to deploying multiple instances of Synapse. While this solution provides isolation it comes with the costs of deployment, maintenance, monitoring, and data migration, currently encountered by Sage for one Synapse instance, but multiplied by the number of deployments we would support.

This document proposes the alternative of creating logical realms within the single Synapse SaaS application, logical partitions that prevent users from sharing data across realms.

Design

A realm would be a construct in Synapse. (Note: The objects can be a hard-coded enumeration, like OIDC providers. CRUD services are not needed to implement realms.) Each realm would have an associated IdP used to create accounts and to authenticate. Users and teams would be associated with a realm. Users within a realm would not have access to resources outside their realm, unless those resources were public, i.e., accessible without any authentication.

Modifications to existing services:

• Creating an account: account (i.e., a user) is associated with a realm and must be created using an IdP associated with the realm. An account must be uniquely and immutably associated with a single realm. Note: It’s OK to use multiple IdPs for a realm. It’s NOT OK to share an IdP across realms, since (1) the IdP will provide the user email, (2) user emails should be globally unique, but (3) a user will have a separate Synapse account in each realm.

• Authentication: must be done using an IdP associated with the realm for a user associated with the realm.

• Create a team: team is associated with a realm, immutably. (The realm is that of the user creating the team.)

• Add/invite a user to a team: invitee’s realm must match team’s realm.

• Create an object which has an ACL: The ACL is associated with the realm.(This applies to all object that have ACLs, including ENTITY, EVALUATION, FORM_GROUP, ORGANIZATION, ACCESS_REQUIREMENT, PORTAL, OAUTH_CLIENT) (Alternatively, the realm of the ACL is implicitly the realm of the initial principal in the ACL, i.e., its creator.)

• Share (change an ACL): only principals (users and teams) in the ACL’s realm may be added to the ACL. (Alternatively, realm consistency in an ACL can be enforced by the rules of adding users: The only users and teams that can be added to an ACL are those which are in the realm of the user managing the ACL.)

• Create local sharing settings: new ACL is associated with the previous benefactor’s realm. (Alternatively, the realm of the ACL is implicitly the realm of its principals. Since local sharing settings start with the contents of the benefactor, the new ACLs is implicitly in the same realm.)

• An OAuth client would be associated with the realm of the user who created it. Any sessions for that client would be in that realm. I.e., users logging in through a linked system would be prompted to log in using the IdP associate with the OAuth client’s realm.

Each realm would have its own values for the following principals:

• Anonymous user

• Public group

• Authenticated users group

• Administrator group

With the limitations described above it is impossible for a content created in one realm to be made accessible to a user in another realm, except by making it publicly accessible.

Note that no objects besides users and teams need have an explicitly associated realm. In particular, entities (projects, folders, files, tables, …) and other objects controlled by ACLs (evaluations & submissions, discussion forums & threads) could have explicit realms, but lacking an explicit realm attribute it’s their ACL which restricts access to their realm. Moreover, avoiding adding an explicit realm attribute allows administrative reorganization of content (e.g., migration of large entities hierarchies between realms).

Note that we are not addressing governance services, i.e., access requirements, submissions, approvals, etc. are not 'realm-specific'. Objects that are private to a user are implicitly in the realm of that user.

Issues

When acting an an OAuth provider, the login page needs to check the realm for the OAuth client and present the appropriate user login.

Legacy content

Synapse would have a default realm to which every existing user and team would belong. The relation could either be implicit or be explicit, backfilling records for existing content.

Related Concepts

Realms are related to, but not the same as Portals and (envisioned) Organizations. A Portal could be associated with a realm and an Organization could have a realm as a component. But realms are strictly for scoping (creating boundaries for) identity and authorization. Portals and (envisioned) Organizations address other concerns. E.g., a Portal has a URL. An Organization might have associated storage and Governance rules.

API Additions

This new API returns an access token for the anonymous user in the given realm. The token is passed as a Bearer token in the Authorization header of subsequent requests which would otherwise be unauthenticated, to indicate which realm the request is for. In the next section we describe how existing services change their behavior, using this token.

API Changes

Priority:

1. Required for MVP.

2. Improves user experience in MVP. E.g., restricting a membership invitation to the user’s realm is not required to restrict team membership to the realm but avoids errors when membership is accepted.

3. Peripheral service, e.g., service only accessible to ACT.