Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 6 Next »

2022-08-09 Update

Based on the discussion at the face-to-face meeting, we think a more typical user-group access-control design is appropriate. Jim Wilson will elaborate use cases and motivation (e.g., new membership/subscription category). Discuss top-down, bottom-up, and reconciling where the two meet.

Origin

This is Jim Wilson's idea on multi-tenant support in Score.

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.

Score

  1. Only OAGi may create business contexts.

  2. Each user’s account must include an email address.

  3. The domain of each user’s email address (just “domain” hereafter) will be stored in a column in the user table separate from the email column.

  4. Each context must have at least one and may have many domains associated with it before a BIE may be created.

  5. Users who belong the domains associated with a context may create and view BIE’s created in that context.

At first, it seemed to Jim that this design was a bit of a hack. On further reflection, it seems not a hack given the “Key points informing the design”.

Alternative design

Basically the same as the design above except that each business context must include a “tenant” context category/value. Domains would be associated tenant context category values with permissions flowing through the tenant context category in each business context.

  • No labels