Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 66 Next »

YOUnite groups an organization's master data resources by the organization's structure (e.g. divisions, departments, districts, etc) and uses these groupings to create relationships within the organization.  With YOUnite these groupings are called zones.

It's important to gain the distinction that:

  • Access to resources is granted through permissions
  • Access to master data is granted through scopes and metadata (covered in the Scopes and Metadata pages).

Zones

As mentioned above, YOUnite provides zones so an organization can group master data resources along its organization structure.

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

Zone characteristics:

  • Zones have users associated with them generally of two types:
    • Zone admin 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 changes and operational events.
  • Zones have zero or more adaptors tied to services containing federated master data.
  • The zone admin controls access to zone resources with the exception of the master data and domains
  • The zone data steward controls access to the master data associated with a zone
  • The zone data steward can restrict in-bound data shared by 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 a single top-level domain creates domains for the entire YOUnite deployment. 

The Ultimate Root Zone

Upon initial deployment, YOUnite creates a root zone called root with a zone admin user mdmadmin.  All zones created are subordinate to it. The UUID of the root zone is always 6c5a754b-6ce0-4871-8dec-d39e255eccc3.The root zone's UUID was necessary when creating the "College District" zone below:

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 (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 Zone admin (more on user types and permissions to follow).

If this is the first zone associated with an 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 Zone Admin.

For example, if the IT admin created above for the college district zone (senor_jefe@college_district.edu) creates a zone called "Central College" and assigns Cece Jones SSO ID as the IT admin for the zone, then a new user (cece@college_district.edu) is created and she will be associated with the "Central College" zone:

If two more zone's are created and Cece is associated with them, the same YOUnite user is used. So now the one YOUnite user (with SSO ID cece@college_district.edu) is associated with three zones:

The  user's permissions are specific to the zone they are logged into. This is accomplished using permissions, policies and groups.


Permissions

YOUnite users can be granted or denied access to resources by setting appropriate permissions. Generally permissions are managed by the zone admin or other users that have been given control over a zone's permissions. 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, MDRs, logs, adapotrs, etc.
  2. Actions: These are the actions the user can perform on the resource. They  include GET, PUT, POST, DELETE, PATCH (and ALL).


TODO: Example Resources

An example permission:

/groups/*ALL

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

Permissions do not stand on their own but are grouped into polices.


Policies

A policy is a group of permissions that can be used to manage users. YOUnite has two default managed polices


Typically there are two types of users associated with a zone that leverage these policies:

  1. Zone 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.The zone admin has general zone management responsibilities such as creating subordinate zones, adding adaptors and other users and attaching policies and permissions to users.
  2. Data Steward: Zone admins can create additional users with data steward permissions. These users have access and manage control (scope) to the master data (covered in the Scopes and Metadata pages).

See the YOUnite API documentation for more specific on policies.




Groups

A group is a collection of users. that has policies associated with it. A group can have multiple policies associated with it and users can belong to more than one group.

Effective Permissions

The user's effective permissions are a union of all the permissions associated with all of the groups they are in and any policies directly associated with them.

The following diagram pulls all of the above topics together and shows how the user's effective permissions are calculated


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


Notifications

TODO


Logging

TODO



API Users

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

  • No labels