Page Comparison

Governance refers to Data Governance in MDM.

What is Governance?

...

ACLs and ACL Chains

 ACLs are a key component of YOUnite and are different from permissions in that they control where data flows through the system. Permissions control who can manage zones, users, groups, permissions, and roles.

An ACL chain can be thought of as a series (chain) of filters policies (ACLs) that can be applied to a data event that occurs in the MDM ecosystem.

...

An access control list, or ACL, is a list of properties that when combined, create a policy that controls data flow between zones and adaptors. The list of ACL properties includes:

...

ACLs are linked together to form ACL chains. They behave similar to network firewall chains but apply to an organizations data entities linked to YOUnite. When a data event occurs to a source entity, the change is transmitted to the YOUnite Router and the appropriate ACL chains are consulted and data is propagated (allowed) or restricted based on the ACLs in the ACL chains. Care must be taken to order the ACLs on a chain properly since the first ACL match is applied to a data event.

...

Outbound ACLs can be thought of as permissions policies on out-bound data. By default, all ACLs are open. Outbound ACLs are the controls a Source Zone's data steward sets on Destination Zones:

Controls Polices can be set on the following:

...

Inbound ACLs can be thought of as permissions policies on in-bound data. By default, all ACLs are open. Inbound ACLs are the controls a Destination Zone sets on Incoming data requests from Source Zones:

Controls Policies can be set on the following - the zone data steward in the destination zone, creates the ACL on behalf of the destination zone:

...

Operation ACLs are not part of zone data governance but should be mentioned briefly here. By default, the DGS has permission to modify ACLs to . Operational ACLs set policies that set forth for a given data domain version:

• What zone can or can't  POST or DELETE  data records (DRs)

...

TODO: Add a POST/DELETE chart

ACLs Illustrated

TODO - Survey examples

...

• . 
• What adaptors or can't  POST or DELETE  data records (DRs).

There is a single system-wide chain for Operational ACLs that is controlled by the DGS.  By default all zones and adaptors can POST and DELETE data records but POST and DELETE polices for data records can be controlled by the DGS.

Operational ACL policies can be on the following:

ACLs Illustrated

A very simple example it illustrate this point:

• There are four three zones: ZoneW, ZoneX, ZoneY and ZoneZ each with only one adaptorZone-X, Zone-Y and Zone-Z each with two adaptors. All adaptors are capable of storing/retrieving data entries for the "Customer" domain
• ZoneW Zone-X has the following outbound ACL chain
• ALLOW all outbound data events from to flow through to ZoneY
RESTRICT all outbound data events from flowing to all zonesOutbound ACL Chain

_{ALL = GET, PUT, POST, DELETE}

1. A Customer PUT data event is raised on adaptor1 in

...

1. Zone-X
2. YOUnite can see that the adaptors in

...

1. ZoneY and ZoneZ are all capable of consuming this data event
   1. YOUnite attempts to route the data event to

...

1. 1. Zone-Y
      1. YOUnite inspects

...

1. 1. 1. Zone-X's outbound ACL chain and gets a match on the first ACL in the chain and routes the  event to the

...

1. 1. 1. two adaptors in Zone-Y
   2. YOUnite attempts to route the data event to

...

1. 1. Zone-Z
      1. The first ACL does not match but the second does restricting the event, so the data event is NOT routed to

...

TODO: Illustrate this

Examples worth mentioning:

Outbound ACL entry that includes domain properties:

• Need to include "allow" PUT and/or POST for them to take effect.
• The domain properties are a list of properties that should be restricted from flowing outbound
• The domain properties are ignored when "restrict" (e.g. restrict PUT or POST) is used since restrict is applied to the entire data event.

As mentioned above, governance provides visibility to data between zones and adaptors. This is typically managed by the ZDS, implemented with Access Control Lists (ACLs). ACLs are a key component of YOUnite. ACLs are different from permissions in that they control access to data. Permissions control who can manage zones, users, groups, permissions, and roles.

ACLs control both:

• Permissions on outbound data
• Controls on what inbound data a zone or adaptor should receive

TODO: Redraw and move to the top and re-use down here

Image Removed

For example, if an update (PUT or PATCH) operation is performed on data under YOUnite control, ACLs would control:

• What zones and adaptors would have visibility to the change (outbound ACLs)
• Which zones and adaptors receive (or reject) the change (inbound ACLs) e.g. a zone may be granted ACLs to a change but the ZDS for the zone may choose not to accept it.

Example Outbound ACLs for GET

These example ACLs are combined to create the effective outbound governance for a zone. DR-XXX represents a specific data record:

...

After applying all of the above, the end result is:

• ZoneX gets nothing
• Zone Y is restricted from seeing the two DRs listed above
• Student.feeWaiver on AdaptorB is not shared with any other zone
• Student.ssn is never shared with another zone (for all adaptors in the outbound zone)

Out-bound data permission is controlled at various levels. See an example of the data access, below.

...

1

...

• At the highest prioirty level (Priority 1), Zone[1] can shut off all outbound data record changes to Zone[2]. At the lowest priority level (Prioirty 5), Zone[1] can shut off sharing a single attribute on a single adaptor (that it owns) to Zone[2].
• Sharing precedence is based on the priority e.g. If Zone[1] has turned off access to Zone[2] (Priority 1), then all other sharing actions are null.
• Permissions for each element are based on REST operations GET, PATCH, POST and DELETE. An additional operation is added for PUSH, where a zone allows another zone to receive real-time changes. However, it may be determined that GET will include PUSH.

1. 1. 1. Zone-Z

Following is more involved example using the zones and adaptors from above. ACLs are evaluated from first to last, the first match is applied to an incoming data event:

_{ALL = GET, PUT, POST, DELETE}

After applying all of the above, the end result is:

• Zone-Y gets nothing
• Zone-Z is restricted from seeing the two DRs listed above
• No data from Zone-X's Adaptor2 flows to any zones or adaptors
• Zone-X never shares the Customer version 1 Domain property Customer.ssn  (for all adaptors in the outbound zones)

Complete ACL Data Flow Illustration

The image below represents an example of MDM domain-related permissions and operational, outbound, and inbound ACLs (traveling left to right). Additional text below the image describes the process in addition to the embedded in-image text.

...

the components involved as a data event is detected at an adaptor and flows through the YOUnite ecosystem.

Image Added

• On the diagram's left side is a source zone’s single Source Adaptor (abcd-1234) that sends data changes (data records) in its domain(s) Zone-X, Adaptor 1) detects a data event in the source system (ERP) and sends a data event (data record for a given domain version)  to the router.
• Note: A zone can have many adaptors.
The data records record sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed (create/delete YOUnite Data Records)  from the source zone’s adaptor(s) and adaptor domain(s) and are defined by the zone's DGS.
• Next, the data records from the source zone’s domains/adaptors are linked to YOUnite Data Records to avoid data record duplication. 
  • Note: The data records published by the source adaptor could be updates, deletes, or new records.
• Outbound ACLs then get applied to the source adaptor’s data recordsrecord (Zone-X, Adaptor 1). The Outbound ACLs are defined by the source zone’s ZDS and define what data the Zone can send out (i.e .restricting data, or elements of data, of certain domains from flowing out of certain adaptors in the zone to other zones).
• After Outbound ACLs are applied the data records are published to the YOUnite Data Hub and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.
• Any destination zone that has subscribed to data records from the source zone has Destination zones have Inbound ACLs in place to define which data operations are allowed in the from source zone zones and its their adaptor(s). Inbound ACL is defined by the destination zone’s ZDS. Any data or operations that are configured to be ignored restricted are filtered out. The Destination Adaptor (zyxw-9876) in the image above is shown receiving data records and/or operations it has subscribed to, as filtered by its zone’s Inbound ACL 
• After Outbound ACLs are applied the data records are published to the YOUnite Data Hub Router and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.