Governance refers specifically to data governance in MDM, and that governance is exercised via Access Control Lists (ACLs) for zones.
Governance: InboundAclEntries and OutboundAclEntries
Governance is what provide visibility to data between zones and adaptors. It is typically managed by the zone's data steward and is implemented with Access Control Lists or ACLs.
ACLs are different from permissions in that they control access to data. Permissions on the other hand control who can manage zones, users, groups, permissions and roles.
ACLs are a key component of YOUnite.
ACLs control both:
- Permissions on outbound data
- Controls on what inbound data a zone or adaptor should receive
ACLs can be thought of as a series of filters that get applied to a data operation.
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.
Outbound Access Control Lists (ACLs)
Outbound ACLs provide data record visibility between zones and adaptors. ACLs are a key component of MDM and are part of what is often referred to as the router.
Outbound ACLs can be thought of as permissions on out-bound data. By default, all ACLs are open. Outbound ACLs are the restrictions a Source Zone sets on a Destination Zone's:
- access to source data (GET) inside the Source Zone
- data operations (PUT, POST and DELETE) inside of the Source Zone
| Operation | Description |
|---|---|
| PUT | When the source zone restricts the changes that occur inside the source zone from flowing outbound to destination zones. |
| POST | When the source zone restricts new data that is created on adaptors in the source zone from flowing outbound to destination zones. |
DELETE | When the source zone restricts "deletes" that occur inside the source zone from flowing outbound to destination zones. |
| GET | What destination zones are restricted from using the source zone's data when assembling data. |
Restrictions can be set on the following:
| Entity | Description |
|---|---|
| Destination Zone | he destination zone |
| Adaptor | A Source Zone's adaptor(s) |
| DR | The union of all data for a specific DR stored on the adaptors (unless constrained to an adaptor) inside the Source Zone |
| Domain | The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the Source Zone that maps to a given Data Domain |
| DomainProperty | The union of all instances of a specific domain property stored on adaptors inside of the Source zone (unless constrained to a subset of adaptors) |
Outbound ACLs are applied from left to right in the following order:
Destination Zone → Source Adaptor → Domain → DomainProperty → DR
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:
| ACLs | Description |
|---|---|
| ZoneX | Restrict all outbound data to ZoneX |
| ZoneX, AdaptorA | This would be useless since ZoneX is already restricted. |
| ZoneX, DR-123 | Again, no need to restrict a specific data record from going to ZoneX since ZoneX is already restricted. |
| ZoneY, DR-123 | OK |
| ZoneY, DR-456 | OK |
| AdaptorB, Students.feeWaiver | Restrict the Students.feeWaiver property stored on AdaptorB from going outbound. |
| Students.ssn | Do not send Student.ssn out from source zone. |
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.
...
By default, all ACLs are open. Inbound ACLs are restrictions a Destination Zone sets on Incoming data requests (GET) and operations (DELETE, PUT, POST) from Source Zones.
| Operation | Description |
|---|---|
| PUT | When the destination zone restricts changes that occur in source zones/adaptors from flowing into the destination zone. |
| POST | When the destination zone restricts new data that is created in source zones from flowing into the destination zone. |
| DELETE | When the destination zone restricts deletes that occur in source zone/adaptors from flowing into the destination zone. |
| GET | What source zone/adaptors are restricted (ignored) by the destination zone when assembling data. |
| Entity | Description |
|---|---|
| Source Zone | The source zone of data flowing into the destination zone. |
| Source Adaptor | The source zone's adaptor(s). |
| Destination Adaptor | The destination zone's adaptor(s). |
| Domain | The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the zource zone that maps to a given data domain. |
| DomainProperty | The union of all instances of a specific domain property stored on adaptors inside the source zone (unless constrained to a subset of adaptors). |
| DR | The union of all data for a specific DRs stored on the adaptors (unless constrained to an adaptor) inside the source zone. |
Inbound ACLs are applied from left to right in the following order:
Source Zone → Source Adaptor → Destination Adaptor → Domain → DomainProperty → DR
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.