Re: Extending Org to support multi-level Orgs (i.e. OU)


Deepak Vij
 

Hi James, let me throw more light on this and provide my perspective on all this. Essentially, what Zongwei is asking for is something that is typically available within an enterprise application platform level. To illustrate a very concrete example, application developers can make use of the general purpose platform level hierarchy mechanism and implement functionality such as resource access control and data visibility in order to enable desired application specific behavior. Let me illustrate this Role-Hierarchy based Access Control requirement typically desired in any enterprise grade application environment.

Hierarchies based Access Control
One can improve the overall efficiency of an enterprise by utilizing the concept of role hierarchies. A hierarchy defines roles that have unique attributes and may be “senior” to other roles. That is, one role may be implicitly associated with permissions that are associated with another “junior” role. In essence, if used appropriately, hierarchies are a natural way of organizing roles to reflect authority, responsibility, and competency.

According to an “Aggregation Hierarchy” approach, hierarchy is composed of hierarchy of roles where higher role is responsible for a superset of privileges/permissions of the lower roles. Organization chart is an example of such hierarchy (CEO->VPs->Mgrs->Employees). In such role-hierarchy based “Manager” role may be implicitly associated with permissions that are associated with another “junior” role (“Employee” role in our example). Essentially, the entire set of data visibility and access control permissions for “Manager” role is {permissions assigned to “Manager” Role} Union {permissions assigned to “Employee” Role}.

To complicate this further, instead of “Aggregation Hierarchy” approach, one could also have support for “Generalization Hierarchy” approach - an inverted tree structure. In “Generalization Hierarchy”, higher role in the hierarchy is more general than the lower role. For example, root node of the hierarchy is the most general role and has the least privileges/permissions, while, leaf node has the maximum privileges/permissions.

To summarize all of the above, mostly all enterprise application platforms provide support for a generic tree like hierarchical structure. I remember PeopleSoft Platform provided such generic tree structure as part of their platform. Once available, one can enable functionality such as “Role Hierarchy based Access Control & Data Visibility”, “Organization Hierarchy based Quota Allocations”, support for “Hierarchical Financial Controls” desired in the financial services industry etc. etc.
Hope this all makes sense. Thanks.

Regards,
Deepak Vij

From: James Bayer [mailto:jbayer(a)pivotal.io]
Sent: Friday, September 11, 2015 8:33 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Extending Org to support multi-level Orgs (i.e. OU)

zongwei, i'm unclear why a single org with multiple spaces, each potentially with their own quota, which is what the cf system does today, does not satisfy the customer's request when using a single cf installation.

for example:

org: foo-org
quota: big-quota

space: foo-east
quota: small-quota

space: foo-west
quota: medium-quota

space: foo-north
quota: [none, defaults to org quota]

On Fri, Sep 11, 2015 at 3:06 PM, Zongwei Sun <Zongwei.Sun(a)huawei.com<mailto:Zongwei.Sun(a)huawei.com>> wrote:
One idea is that Org will refer to itself and form a TREE structure. The most descendant Org instance in the hierarchy will have a Space instance. Any parent Org won't have Space.

-Zongwei



--
Thank you,

James Bayer

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.