Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Governance refers to Data Governance in MDM.

...

Operation ACLs are not part of zone data governance. 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). 
  • 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:

EntityDescription
Domain VersionThe domain version an operational ACL applies to.

Source Zone

The zone that is allowed to or, restricted from POSTing a data record (DR).
Source AdaptorThe adaptor that is allowed to or, restricted from POSTing a data record (DR).
Allow POST / Restrict POSTAllow or restrict the source zone or adaptor from creating a data record for the given domain version.
Allow DELETE / Restrict DELETEAllow or restrict the source zone or adaptor from deleting a data record for the given domain version.

ACLs Illustrated

A 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 Outbound ACL chainChain

Source ZoneDestination ZoneDestination AdaptorDomain VersionPolicy
1ZoneWZoneYALLALLALLOW ALL 
2ZoneWALLALLALLRESTRICT ALL 

ALL = GET, PUT, POST, DELETE

  1. A Customer PUT data event is raised on adaptor1 in ZoneW
  2. YOUnite can see that the adaptors in ZoneX, ZoneY and ZoneZ are all capable of consuming this data event
    1. YOUnite attempts to route the data event to ZoneX
      1. 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
    2. YOUnite attempts to route the data event to ZoneY
      1. The first ACL does not match but the second does restricting the event, so the data event is NOT routed to ZoneY
    3.  ZoneZ is restricted as well

TODO HERE

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

...

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:


Source ZoneSource AdaptorDestination ZoneDestination AdaptorDomain VersionData RecordsPolicyNotes
1ZoneWALLZoneXALLALLALLRESTRICT ALL

Restricts all outbound data events to ZoneX

2ZoneWALLZoneXAdaptor1ALLALLRESTRICT ALLThis ACL is useless since ACL #1 already restrict all events to ZoneX
3ZoneWALLZoneYALLCustomer v1DR-123, DR-456RESTRICT ALLRestricts the data records (DR-123 and DR-456) from going to ZoneY.
4ZoneWAdaptor2ALLALLALLALLRESTRICT ALLRestricts data events from flowing out of ZoneW's adaptor2 to all zones.
5ZoneWALLALLALLCustomer v1Customer.ssnRESTRICT ALLRestricts a customer's SSN from flowing out of of ZoneW.
6ZoneWALLALLALLALLALLALLOW ALLAllow everything else out i.e. if a data event can be delivered to many adaptors in the YOUnite ecosystem it will be delivered to all adaptors except for the restrictions placed by the above ACLs. ALLOW ALL is the default so in reality, this ACL is unnecessary. 

ALL = GET, PUT, POST, DELETE

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

  • ZoneX gets nothing
  • ZoneY is restricted from seeing the two DRs listed above
  • No data from ZoneW's Adaptor2 flows to any zones or adaptors
  • ZoneW never shares Customer.ssn  (for all adaptors in the outbound zones)

Complete ACL Data Flow Illustration

...

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

...