/
Multi-tenant

Multi-tenant

Team

OAGi

NIST

Accedia

Resources

Resource name

URL

Notes

Resource name

URL

Notes

This wiki page and child pages

 

GitHub: Score code

 

GitHub: Score documentation

 

GitHub: Score test cases

 

Slack

  • Account: OAGi

  • Channel: #score-multi-tenant

 

Auth0 admin

 

Code contribution guidelines

 

Issue management notes (GitHub issues)

 

Issue management content

 

Test development and execution

  • TBD

 

Docker Hub

 

Terminology notes

  • It is debatable whether multi-tenant is appropriate to describe this feature, but the name has stuck, so we’re using it.

  • role is a critical feature of authorization in this requirements document. In this requirements document, we will use role-related terms as follows:

    • Score role: One of the built-in Score roles (Admin + Developer, Admin + End User, Developer, and End User)

    • Auth0 role: A role defined in Auth0 (this is not relevant for Phase 1 design)

    • tenant: An Auth0 role defined for the purposes of enabling the requirements expressed in the document.

    • role: The meaning could be any of the above depending on the context in which it is used. @Jim Wilson recommends avoiding use of role in favor of one of the three terms above.

  • access BIEs refers to creating, editing, viewing, and expressing BIEs (anything with BIEs)

  • BC: an abbreviation for Business Context

  • Dev/Admin: a user in the Admin+Developer Score role

  • user's tenancy: refers to association of a user to tenants, or more specifically, the association of a user to a valid value specified for the Tenant context scheme

  • Tenant context scheme: The context scheme specified in Score with the name Tenant

Background

OAGi needs:

  1. to enable multiple sets of users to use one Score instance

  2. to be able to limit access to BIEs created by one set of users to members of that set, and other select sets as appropriate

Key points informing the design

Accedia note

While all of these things are true, there is nothing for Accedia to do in response. It is up to OAGi to ensure that the design supports these points. That said, it may be helpful for Accedia to understand our intent (some points) and things that are true about Score’s functionality today (the other points).

  1. Keep the implementation simple until such time that simple won’t work.

  2. The following BIE-development roles/purposes must be supported

    1. OAGi develops BIEs for the public (e.g., SME Express Pack)

    2. OAGi develops BIEs for members only (none yet)

    3. Companies develop BIEs for their company only

    4. Companies develop BIEs for their industry (e.g., MilliporeSigma for the Biopharma industry)

    5. Industry associations or consortiums develop BIEs for their industry (e.g., AgGateway)

  3. Except for 2.c., there is little/no risk for a company’s confidential information to be publicly disclosed.

  4. In the case of 2.c. for company whose BIE design or documentation is highly sensitive, OAGi will advise them to use an on-prem instance.

  5. Each BIE is associated with one or more business contexts.

  6. Each user must be in one of the Score roles.

Phase 1 Design

Multi-tenant Score design

  1. Phase 1 of Multi-tenant Score will use the current built-in capability for authentication, and for authorization of Score roles. Accedia will develop further authorization functionality based on a user’s tenancy.

  2. Score 2.5 and later will be released with:

    1. A context category named Tenant

    2. A context scheme named Tenant (based on the context category Tenant)

  3. No user (not even Dev/Admin) may delete or rename the Tenant context scheme (Accedia will need to implement restrictions.)

  4. No user (not even Dev/Admin) may delete or rename the Tenant context category. (Accedia will need to implement restrictions.)

  5. Only Dev/Admin may manage values in the Tenant category scheme. (Accedia will need to implement restrictions.)

  6. Dev/Admin may manage all business contexts, whether or not the user is associated with any tenant. (This is supported today, but Accedia will need to ensure that other restrictions it implements do not inadvertently restrict this.)

  7. Only Dev/Admin may add or delete a Tenant context scheme value to a BC that has BIEs associated with it. (Accedia will need to implement restrictions.)

    1. Why? This should prevent two undesirable situations:

      1. a user assigning a Tenant context scheme value to a BC that does not have one assigned, thereby restricting access to that BIE

      2. a user assigning another Tenant context scheme value to a BC that already has a Tenant context scheme value associated with it, thus potentially unintentionally enabling access to many users

  8. When creating a BC, users may only use Tenant context scheme values matching the user's tenancy. (Accedia will need to implement restrictions.)

  9. Only a user with the appropriate tenancy may manage a business context containing a Tenant context scheme value. (Accedia will need to implement restrictions.)

  10. Users may be associated with zero or more tenants where the possible tenants are those specified as valid values for the Tenant context scheme. (Accedia will need to develop new functionality, including database changes/additions that store data about the associations.)

  11. A user may only access BIEs:

    1. associated with at least one business contexts that has as least one Tenant context scheme value matching the user’s tenancy.

    2. associated with business contexts that do not include a Tenant context scheme value.

Another way to think about #11 is that if any context associated with a BIE has a Tenant context scheme value, then access to that BIE is determined by the user’s tenancy (except for Dev/Admin). Otherwise anyone can access the BIE.

Logical process for determining whether a BIE is accessible

  • Is the user Dev/Admin?

    • Yes → The BIE is accessible

    • No → Is the BIE associated with a business context containing a Tenant context scheme value?

      • No → The BIE is accessible

      • Yes → Is the BIE associated with a business context containing a Tenant context scheme value associated with the user’s tenancy?

        • Yes → The BIE is accessible

        • No → The BIE is not accessible

Implementation

Accedia manages this section.

Update database structure

We plan to start the multi-tenancy implementation with the following DB changes:

  • Replace the organization column in the app_user table with a foreign key to a new table, called organization, that will be used for the tenants

  • Create a mapping table between organizations and business contexts (many-to-many) that will keep track of each tenant’s access to BIEs in a certain business context

Phase 2 Design (in progress)

Identity Provider

OAGi has an Auth0 account and has been using it for #E authentication and authorization. Following are a couple of screen captures that illustrate how it can be configured to support Score multi-tenant.

Figure 1
Figure 2

 

Related content

Multi-tenant authorization
Multi-tenant authorization
Read with this
Multi-tenant (before requirements simplification)
Multi-tenant (before requirements simplification)
More like this
Multi-tenant (Serm's comments)
Multi-tenant (Serm's comments)
Read with this
Multi-tenant documentation
Multi-tenant documentation
More like this
IOF Membership Policy
IOF Membership Policy
Read with this
To Do's to allow Accedia (or others) to do OAGIS release with Score
To Do's to allow Accedia (or others) to do OAGIS release with Score
More like this