[
https://issues.apache.org/jira/browse/TC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962816#comment-15962816
]
ASF GitHub Bot commented on TC-184:
-----------------------------------
Github user nir-sopher commented on a diff in the pull request:
https://github.com/apache/incubator-trafficcontrol/pull/433#discussion_r110647853
--- Diff: traffic_ops/app/lib/API/Tenant.pm ---
@@ -162,11 +179,17 @@ sub create {
return $self->alert("Tenant name is required.");
}
+ #not allowing to create additional root tenants.
+ #there is no real problem with that, but no real use also
my $parent_id = $params->{parentId};
if ( !defined($parent_id) ) {
return $self->alert("Parent Id is required.");
}
+ if (!verify_tenancy_for_write($self, $params->{parentId})) {
--- End diff --
The read/write separation came to ease the move to more complicated
relationships between tenants in the future.
What I really aimed to is a read/write function per tenant anchor:
verify_tenancy_for_tenant_read/verify_tenancy_for_tenant_write
verify_tenancy_for_user_read/verify_tenancy_for_user_write
verify_tenancy_for_ds_read/verify_tenancy_for_ds_write
verify_tenancy_for_cdn_read/verify_tenancy_for_cdn_write
and maybe more (e.g.
verify_tenancy_for_profile_read/verify_tenancy_for_profile_write).
The need of such an interface is the support of more complicated tenants
relationships. Most cases are indeed indirectly covered by the AAA but not all.
For example, the ISP admin has the ability to manage parameters within a
profile. The CP admin also has this capability, as a profile can be now set to
a DS.
If now I want to allow the users of ISP1 tenant to view profiles of CP1
tenant, but not to edit them, I need to distinguish read and write on the
tenancy level.
The functional API I'm adding now is far from being complete. Much more
should be considered when deciding on the final one. For now I only separate
read&write to simplify further changes.
Additionally, this separation has an added value, allowing LDAP users to
view all data but not write to it.
> Tenant Hierarchy
> ----------------
>
> Key: TC-184
> URL: https://issues.apache.org/jira/browse/TC-184
> Project: Traffic Control
> Issue Type: New Feature
> Components: Traffic Ops
> Reporter: Ryan Durfey
> Labels: Access, Tenancy
>
> Design under discussion here:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910
> The requirements below are seed requirements and final design guidance should
> defer to the evolving wiki page discussion referenced above.
> Overview
> The goal of this system is to create a hierarchical tenancy system which is
> very simple to understand and administer and is highly expandable so that
> large organizations with many subsidiaries have the flexibility to create
> child-tenants to their liking.
> General Seed Requirements
> 1. Provide a structure to create a hierarchy of Tenants where each Tenant has
> a single parent-Tenant and can have multiple child-Tenants
> 2. Provide the ability to group multiple Delivery Services, Users, and child-
> Tenants under each Tenant
> 3. Provide the ability to create at least 10 child-Tenant layers within the
> system
> 4. Make it easy to assign a User to a single Tenant so that they inherit
> their permissions to all child-Tenants and Delivery Services.
> 5. Adding child-Tenants or Delivery Services anywhere in an existing tenant
> hierarchy does not require re-assigning users. Users inherit pre-defined
> permissions to new tenants and services added below their assigned layer in
> the tenancy tree.
> 6. Allow Users to be assigned multiple Tenants, each with different Roles.
> While a user would inherit their access to all services and child Tenants
> below them, they may need more restrictive access further up the Tenant
> hierarchy or they may want different access to another branch of the tenant
> tree.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
