Page Comparison

Zones

Zones are associated with each other in a hierarchical structure with parent, child, and sibling zones e. g. the The following diagram illustrates a college district as the parent zone with three child college zones (. The three child college zones are siblings of each other).:

Image RemovedImage Added

Zone

Characteristics

Zones have

the the following characteristics:

• A person responsible for general zone management . The zone admin is defined when the zone is created.
• Zone data steward Responsible for the domains, data and data governance.

User types are defined by polices. Polices are covered below.

• Zones receive notifications of master data (Zone Admin).
• A person/persons responsible for the data, data domains, and data governance for the zones they are responsible for (Zone Data Steward).
• A named set of permissions that can be assigned to a user (Roles).
• A combination of Users and Policies that are assigned Permissions (Groups).
• Systems that publish and/or subscribe to data to be shared through MDM (Zone Users).
• Notifications of data record changes and operational events.
• Zones have zero Zero, one, or more adaptors tied to services containing federated master data.The zone admin controls that map entities stored in services to federated data domains.
• Controlled access to zone resources (controlled by the Zone Admin) with the exception of the master data and domainsThe zone data steward controls adaptor-associated data.
• Controlled access to the master data entities associated with a zoneThe zone data steward can restrict 's adaptors (controlled by the Zone Data Steward).
• Restricted out-bound and/or in-bound data shared by with/from other zones .
• Centralized YOUnite logs are indexed on a per-zone basis
• A zone data steward can define and share data domains (domains) but generally (managed by the Zone Data Steward).
• Defined and shared data domains. Generally a single top-level domain creates domains for the entire YOUnite deployment . (managed by the Zone Data Steward).
• Centralized YOUnite logs are indexed on a per-zone basis.

The

Root Zone

Upon initial deployment, YOUnite creates a root zone called root with a zone admin called Zone Admin user called: mdmadmin.  All All subsequently-created zones created are subordinate to itthe root zone.

The UUID of the root zone is always always: 6c5a754b-6ce0-4871-8dec-d39e255eccc3.The root zone's UUID was necessary when creating the "College District" zone below:

Image Removed

For example:

POST /zones

Headers:

Content Type: application/json

Authorization: Bearer bearer-token

{
 "name": "Central District",
 "description": "The College District Zone for the West, Central and East Colleges",
 "parentZoneUuid": "6c5a754b-6ce0-4871-8dec-d39e255eccc3",
 "zoneAdminSsoId": "senor_jefe@college_district.edu"
}

Zone Users

A zone is created by a user with an SSO ID

Image Added

Users

Anchor
usersSection usersSection

After the root zone creation, subsequent zones are created by associating a new or existing Zone User with an SSO ID to it. (TODO See YOUnite and SSO Providers). The zone creation request includes an SSO ID. This user is tied to this zone and becomes the zone's IT admin (more on user types and permissions to follow).If this is the first zone associated with the SSO ID, a YOUnite User (user) is created that is tied to the SSO ID. This first zone user has full administrative privileges for the zone and is called the zone's IT Admin (more on user types and privileges to follow). For example, if the IT admin created above for the college district zone (. Zone Users can either be systems that publish and/or subscribe to data to be shared through MDM, or Zone Users can be roles performed by either a Zone Administrators or a Zone Data Steward. 

• A zone can not be created without the associated SSO ID.
• The first Zone User associated with a zone becomes the zone's Zone Admin. The Zone Admin has full administrative privileges for the zone.

An organization's first, initial zone associated to an SSO ID also has a YOUnite User (User) created and tied to the associated SSO ID.

For example, imagine that an IT Admin, Senor Jefe, was associated with the College District zone in the example above. Senor Jefe's SSO ID is senor_jefe@college_district.edu)  creates a zone called . He is the Zone Admin for the College District zone. Senor Jefe creates the "Central College" zone and assigns Celia DevopsproIT Admin Cece Jones's SSO ID as the IT admin for the zone, then a new user to it. Cece Zones is the Zone Admin for the "Central College" zone and also has a new YOUnite User (cece@college_district.edu) is created and that is associated with the "Central College" zone:

Image RemovedImage Added

If two more zone's are created and Cece's SSO ID is associated with them, the her same YOUnite user User name is used . So now the one YOUnite user for all associated zones. If Cece's SSO ID is associated with the other two college zones in the example above, her one YOUnite User (with SSO ID cece@college_district.edu) is associated with all three zones:.

The zone user's YOUnite User permissions are specific to the zone

Typically there are two types of users associated with a zone:

1. IT Admin: These users have zone admin privileges. As mentioned above, the first Zone Admin has full administrative privileges for the zone but additional policies and permissions can be configured that restrict access to other zone admins.
2. Data Steward: Zone admins can create additional users with data steward permissions. These users have access to the master data.
   Image RemovedImage Removed

If the same user creates subsequent zones a new YOUnite user is not created but the SSO ID is associated with the newly created zone. 

Each zone can have multiple users and each user must be tied to an SSO ID.

The following is needed to create a zone:

1. An OAuth bearer token returned from the YOUnite OAuth service (see Authorization header)
2. The parent zone's UUID (see parentZoneUuid in the request body)
3. The SSO ID of the user designated as the zone admin (see zoneAdminSsoId in the request body)

There are two distinct zone responsibilities:

1. General Zone Management The primary zone management user is the zone admin but other users can be created with a subset of permissions.
2. Master Data Stewardship The user responsible for the domains, data and data governance.

The zone admin they are logged into and may be different from one zone to another. This is accomplished using permissions, roles, and groups. 

Groups

A Group is a collection of Users in a zone that has roles associated with it. A group can have multiple roles associated with it and Users can belong to more than one group. In the context of MDM, Zone Administrators combine Zone Users and Policies together in a group making it easier to assign Permissions. For example, a group can be defined that has permission to certain systems within a zone or multiple zones. Then users can be assigned to the group and inherit the permissions for that group.

See the YOUnite API documentation for more specifics on zones, users, groups and roles.

Roles

Anchor
rolesSection rolesSection

A role is a named set of permissions that can be assigned to a user to manage their resource access.

There are two different kinds of roles:

• Managed Roles that manage system permissions and features
• Custom Roles that are defined by the Zone Admin or Zone Data Steward 

Managed Roles

Anchor
managedRoles managedRoles

YOUnite has two default managed roles: Zone Admin and Zone Data Steward. These two managed roles are visible to all zones and can not be deleted.

Image Added

Image Added

The Zone Admin:

• controls access to zone resources with the exception of the data associated with the adaptors.

The Zone Data Steward:

• controls access to the data entities associated with a zone's adaptors.
• can restrict either out-bound or in-bound data shared with or from other zones.
• can define and share data domains (domains) but generally a single top-level domain creates domains for the entire YOUnite deployment. 

Custom Roles

The Zone Admin can create custom roles.

• Zone Admin: As mentioned in the Users section above, the first Zone Admin has full administrative privileges for the zone but additional roles and permissions can be configured that restrict access to other Zone Admins. The Zone Admin has general zone management responsibilities such as creating subordinate zones

The zone admin can associate users from other zones with their zone and set policies and permissions for them to operate in the zone as well.

• , adding adaptors, creating/managing groups and Users, and attaching Roles to Groups and individual Users. Zone Admins can create additional Users with Data Steward permissions.
• Zone Data Steward: These Users have access and manage control (governance) to the data records (covered in the Scopes & Metadata and Governance pages).

Image Added

Image Added

See the YOUnite API documentation for more specific on roles.

Permissions

YOUnite users can be granted or denied access to resources by setting appropriate permissions for them. Generally permissions . Permissions do not stand on their own but are grouped into Polices (which are explained below). Permissions are managed by the zone admin Zone Admin or other users that have been given control over a zone's permissions.

Policies

A policy is a group of permissions that can be used to manage the general role of YOUnite users. By default ....

Groups

A group is a collection of YOUnite users. The zone admin can use groups to specify permissions for a collection of users. 

See the API documentation for TODO UES.

Notifications

TODO

API Users

An API consumer for the zone can register a callback URL to receive notifications of events such as completed transactions.

Think of permissions as being grouped together into roles.

Permissions are broken out into two properties:

1. Resource URI: The YOUnite resource that is part of the user's zone. If the zone user has the appropriate permissions, they can allow other users to access a resource such as a domain, logs, adaptors, etc.
   
2. Actions: These are the actions the user can perform on the resource. They include GET, PUT, POST, DELETE, PATCH (and ALL).

Permission Example

In the example below a user is granted full access to all domains (resources) in the zone except for:

• staff: The user has no access to the staff domain
• students: The user has full access to the students domain excepting the DELETE action

Any user with this permission can create, modify, delete, and view all other user's for a zone.

Effective Permissions

In particular zone, the User's effective permissions are a union of all the permissions associated with all of the groups that he or she is in and any roles directly associated with them.

The following diagram pulls all of the above topics together and shows how the user's effective permissions are calculated   ( TODO graphic below needs to be fixed to say roles instead of policies. )

Image Added