Page Comparison

Governance refers to Data Governance in MDM.

...

Governance describes the act of managing data access (i.e. who accesses certain data sets based on role, application, etc.).

ACLs and ACL Chains

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

ACLs

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

• Source Zone - The zone the data originated from
  • Source Adaptor - The adaptor the data originated from
• Destination Zone - The zone the data is flowing to
  • Destination Adaptor - The adaptor the data is flowing to
• Domain Version - The data domain the ACL applies to
  • Domain Version Properties - One or more properties in the data domain that are applied to the ACL
• Data Records - One or more data records that are applied to the ACL
• Allow/Deny settings for an ACL control which operations are either allowed or denied:
  • GET
  • PUT
  • POST
  • DELETE

Data events in YOUnite parallel the HTTP requests GET, PUT, POST and DELETE

...

If any of the above controls are omitted from an ACL, then ALL is assumed.  (TODO - Add this later).

Not all ACL types use all of the ACL properties.

ACL Chains

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 YOUnite 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 on out-bound data. By default, all ACLs are open. Outbound ACLs are the restrictions controls a Source Zone's data steward sets on Destination Zones:

...

...

Restrictions Controls can be set on the following:

Outbound ACLs are applied from left to right in the following order:

    Destination Zone → Destination Adaptor → Domain → DomainProperty → DR

Inbound ACLs

...

Inbound ACLs

Inbound ACLs can be thought of as permissions on in-bound data. By default, all ACLs are open. Inbound ACLs are controls a Destination Zone sets on Incoming data requests (GET) and operations (DELETE, PUT, POST) from Source Zones.:

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

Inbound ACLs are applied from left to right in the following order:

...

Operational ACLs 

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 data records (DRs) to zone users and adaptors to create new DRs. Operational ACLs control operations to the underlying DRs are granted by the DGS to Zone Users and Adaptors; typically the ZDSs.

TODO: Add a POST/DELETE chart

ACLs Illustrated

TODO - Survey examples

I very simple example it illustrate this point:

• There are four zones: ZoneW, ZoneX, ZoneY and ZoneZ each with only one adaptor. All adaptors are capable of storing/retrieving data entries for the "Customer" domain
• ZoneW has the following outbound ACL chain
  1. ALLOW all outbound data events from to flow through to ZoneY
  2. RESTRICT all outbound data events from flowing to all zones
• A Customer PUT data event is raised on adaptor1 in ZoneW
• YOUnite can see that the adaptors in ZoneX, ZoneY and ZoneZ are all capable of consuming this data event
  • YOUnite attempts to route the data event to ZoneX
    • YOUnite inspects ZoneW's outbound ACL chain and gets a match on the first ACL in the chain and routes the  event to the adaptor in ZoneX
  • YOUnite attempts to route the data event to ZoneY
    • The first ACL does not match but the second does restricting the event, so the data event is NOT routed to ZoneY
  •  ZoneZ experiences the same fate as ZoneY

TODO: Illustrate this

Examples worth mentioning:

...

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

ACLs

...

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

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

...

• 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.

PROBABLY WANT TO REMOVE MOST OF THE FOLLOWING - Illustration is for devs but should be modified

...

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.

...

• 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) to the router.
  • Note: A zone can have many adaptors.
• The data records sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed 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 records. 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 Inbound ACLs in place to define which data operations are allowed in the source zone and its adaptor(s). Inbound ACL is defined by the destination zone’s ZDS. Any data or operations that are configured to be ignored 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.

...