Tenancy


Click to edit this diagram on draw.io

Proposed Logic

  1. A CDN is made up of a hierarchy of Tenants 
  2. Each Tenant can only have one parent Tenant
  3. Each Tenant can be assigned many child Tenants
  4. Each Tenant can be assigned many Services
  5. Each Service is assigned to only one Tenant
  6. Each Tenant can be assigned many Users
  7. Each User is assigned to at least one Tenant
  8. Each User may be assigned to many Tenants (opt)
  9. Users inherit access to all child Tenants and Services below the Tenant they are assigned

Operational Improvements

  1. When a new service is added below a tenant all users up the tree inherit access automatically.
  2. When a new user is added to a tenant the user inherits access to all services below the tenant automatically.
  3. Service data for a tenant can be rolled up across all sub-tenants and services allowing grouping of data and reporting.
  4. Note that access level is determined separately from tenancy.  Users within the same tenant may have different access levels ranging from admin level to read only.

Example of Tenant Hierarchy

Click to edit this diagram on draw.io

 

 

 

  • No labels

4 Comments

  1. Jeremy Mitchell

    Tenancy will involve more than the scoping of "services" aka delivery services. It actually is intended to scope all CDN resources where delivery service is just one of those resources. For example, servers (or caches) are another type of CDN resource. So, if you try to fetch a list of servers via /api/version/servers, you will only see the servers belonging to a tenant in your tenant list. So maybe you want to incorporate that into your diagram...or maybe just make it clear that this page is really intended to show how tenancy and delivery services fit together...

  2. Ryan Durfey

    So I think Servers will still be assigned to Services and not Tenants.  A Tenant could have multiple Services which use different Server sets that are tuned to different types of delivery like Live, SSL, small object, etc...  To me Tenants is simply a grouping system for Services and Users.  

  3. Jeremy Mitchell

    Tenancy is used for more than just users and services (deliveryservices). In fact, it is used for all CDN resources if applicable. Let's follow an example:

    Tenant hierarchy

    - root
    -- ISP 1
    --- Tenant 1
    ---- subtenant 1-a
    ---- subtenant 1-b
    --- Tenant 2
    ---- subtenant 2-a
    ---- subtenant 2-b
    -- ISP 2
    --- Tenant 3
    ---- subtenant 3-a
    ---- subtenant 3-b
    --- Tenant 4
    ---- subtenant 4-a
    ---- subtenant 4-b

    Users, deliveryservices and cdns are assigned a tenant like so:

    +-----------+------------------+----------------------------+
    | user | role | tenant |
    +===========+==================+============================+
    | bob | cdn-admin | ISP 1 |
    +-----------+------------------+----------------------------+
    | sam | tenant-admin | Tenant 2 |
    +-----------+------------------+----------------------------+

    +----------------+--------------------+
    | cdn | tenant |
    +================+====================+
    | cdn1 | ISP 1 |
    +================+====================+
    | cdn2 | null |
    +================+====================+

    +----------------------+--------------------+
    | deliveryservice | tenant |
    +======================+====================+
    | foo-ds | Tenant 1 |
    +======================+====================+
    | bar-ds | Tenant 2 |
    +======================+====================+
    | baz-ds | null |
    +======================+====================+


    Bob's results:

    - GET /api/../deliveryservices <-- returns ds's where tenant=null or tenant=ISP 1 (or a child tenant of ISP 1)
    - GET /api/../deliveryservices/:id <-- returns 200 only if ds.tenant=null or ds.tenant=ISP 1 (or a child tenant of ISP 1)
    - GET /api/../cdns <-- returns cdn's where cdn.tenant=null or cdn.tenant=ISP 1 (or a child tenant of ISP 1)
    - GET /api/../servers <-- returns servers that belong to a cdn where cdn.tenant=null or cdn.tenant=ISP 1 (or a child tenant of ISP 1)

    Sam's results:

    - GET /api/../deliveryservices <-- returns ds's where tenant=null or tenant=Tenant 2 (or a child tenant of Tenant 2)
    - GET /api/../deliveryservices/:id <-- returns 200 only if ds.tenant=null or ds.tenant=Tenant 2 (or a child tenant of Tenant 2)
    - GET /api/../cdns <-- note: as a tenant-admin, he probably can't get here anyhow, but if he could returns cdn's where cdn.tenant=null or cdn.tenant=Tenant 2 (or a child tenant of Tenant 2)
    - GET /api/../servers <-- returns servers that belong to a cdn where cdn.tenant=null or cdn.tenant=Tenant 2 (or a child tenant of Tenant 2)

    any resource that can be mapped back to a ds or a cdn will have tenancy enforced (if ds.tenant or cdn.tenant is not null). this allows us to scope ALL cdn resources (where possible) according to the user's tenant. also, note that tenancy is optional. if you leave tenant to null on a ds or a cdn, then all the related resources will not have tenancy enforced. 

    1. Nir B. Sopher

      I believe that 2 additional resources would probably have tenancy set directly in the database.
      First - the tenant itself. The parent is the "owning tenant" of the "tenant resource" .
      Second "profile". Parameters tenancy would be derived from the profile they are assigned to.