Terminology notes

• It is debatable whether multi-tenant is appropriate to describe this feature.

• role is used as a critical feature of authorization. Perhaps group would be more appropriate, or at least natural, but role is what Auth0 provides out-of-the-box, so we'll go with it.

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

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

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 should advise them to use an on-prem instance.

5. Each BIE must be “in” a business context.

Design

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.

Open

Figure 1

Open

Figure 2

Multi-tenant Score design

1. This design only affects BIE access. This design would not apply to CC access.

2. Score will use Auth0 for authentication and authorization.

   1. Out of the box, Auth0 supports

      1. Managing users

      2. Managing roles

      3. Managing user-role relationships

3. Only administrators may manage business contexts in Score.

4. Each business context may have zero-to-many roles associated with it (managed only by administrators). See Figure 3.

   1. There are many ways to design the UI to show roles associated with a business context and to add/delete them. Figure 3 is just one example.

   2. The built-in roles will be supported (end user, developer, admin) as Score_End_User, Score_Developer, and Score_Admin roles in Auth0.

   3. Tenant role names in Auth0 will begin with Score_Tenant_ followed by a short name. E.g., Score_Tenant_AgGateway.

5. A user may only access BIEs associated with business contexts that are associated with one of the user’s roles.

Logical process for determining what BIEs to show in the BIE list

See NIST/OAGi Score.

• For each BIE

  • For each of the BIE’s business contexts

    • For each of the business context’s roles

      • Is the user in that role?

        • Yes: Show the BIE in the list.

        • No: Don’t show the BIE in the list

Concrete example

Roles

1. Admin

2. Developer

3. End User

4. AgGateway (tenant)

5. ACME Brick (tenant)

6. HR Open Standards (tenant)

Business Contexts

1. Human Resources

2. Agriculture

3. Construction

4. Entertainment

Users

1. Bob

2. Mary

3. Amy

4. Roy

5. Matt

6. Tess

7. Ross

BIEs - Business Contexts

Users - Roles

Business Contexts - Roles

BIE Visibility to Users

This table would be computed based on the values in the tables above.

• Mary can access all BIEs because she is in the Admin role. Administrator can see everything.

• Matt can only access BIEs in a business context associated with the ACME Brick role.

• Tess can only access BIEs in a business context associated with the AgGateway role.

• Ross can only access BIEs in a business context associated with the ACME Brick role or the AgGateway role, which in this example computes to be all of them.

Analysis about how this change could impact current on-prem users (and existing OAGi instances of Score), assuming we go with the BC approach

1. Actually current roles in Score are below.

   1. Developer

   2. Admin developer

   3. End user

   4. Admin end user

2. There is no difference b/w being admin or not being admin in term of the BIEs Access. So, it is okay to simply refer to Developer and End User here. But these have to be differentiated in the authentication server.

3. When current instances of Score get upgraded to a multi-tenant version, roles have to be assigned to existing business contexts. Here are to options to keep the current accesses to existing BIEs

   1. Assume that BCs that have no roles assigned are accessible by any role. Keep in mind that a BIEs can have multiple BCs, going forward, if these BCs have different roles, what shall the application do? Should it taking the union or intersection to give permission? It is something, we have to decide regardless of this issue.

   2. Assume that Developer, Admin Developer, End User, and Admin End User can always access all BIEs even though these roles are not present in BCs.

   3. All existing business contexts will be assigned all four roles when making upgrade to the multi-tenant version.

   4. Apparently, approach (a) is simpler. And for convenience, we mighty assume (c) as well. I don’t see any issue with that at this point. It means that the current BIEs in OAGi instances will be accessible to all, but that can also be changed later on.

4. About the business contexts, currently anybody can manage business context. If the multi-tenant version restricts this to only Admin Developer or Developer, this can cause an issue with existing customers.

   1. Alternatives are:

      1. Make it an installation option to who can manage the BCs.

      2. Make an inform decision with current users. Maybe this is a best practice to limit BC management to only Developer role.

      3. Change the multi-tenant requirement to “Only Developer can manage BC/Role Assignment”. In other words, everyone is still free to create and manage the BC content itself but only Developer can assign roles to BCs. We have to think about BCs discard function, b/c right now anyone can discard BCs if there is no associated BIE - and this is likely still ok.

   2. Option (iii) seems simplest.

So this seems quite manageable.

Analysis b/w using Business Context & Role vs. using only Role to control BIE access

<serm>Using both BC and Role approach seems like a win between the two. OTOH, maybe we should consider the multiple DB schemas option as well. I think this option is not necessarily more complicated to implement. See below where EUCCs management gets complicated.

Also, there is an option of deploying private instances. This option may be implemented with a simple authentication server that directs the log in user to the designated endpoint. This option just incurs more administrative burden and may cost more for computing resource. But as you @Jim Wilson said this would be a good problem to have.

</serm>

Additional things to consider

1. Are all other user roles that are not Developer, Admin Developer, End User, and Admin End User considered subclasses of End User role? In other words, users in these roles inherit behavior of End User, e.g., they cannot create account, they cannot manage developer CCs, they can extend BIEs.

2. Note that if they can extend BIEs, it means that we have to also implement access logic on the CC side where they can manage only end user CCs. However, end user CCs have no BC assigned, so how to we infer access authorization? <serm>I couldn’t think of a nice and simple solution to this. The simplest thing to do, which sounds like a hack, is to do not allow BIE extension for users that are not End User or Admin End User. Another option is to inferred, roles associated with CCs from BIEs they are used in, but some EUCCs may not yet be used in any BIEs. Or we can say that if they are not used yet then only the owner can access it. </serm>. EUCCs logic also have to change in that only EUCCs with the same access authorizations can be used together, but what if the access authorizations change later on. This is getting pretty real complicated.

3. It looks like more sophisticated user role management functionality will need to be implemented in Score. For example, currently a user account cannot have multiple roles, e.g., an account cannot be both Developer and End User. We will still have to implement a user role management logic to do not allow the user account to have these two roles. Or that the user must select a role when he logs in, i.e., he cannot hold multiple roles when logging in. Also I think whether a CC or BIE is a Developer CC/BIE or End User CC/BIE, is inferred from the owner user. If the user can have multiple roles during the session, this logic can be affected.