YOUnite can group an organization’s resources to mirror the organization’s structure (e.g. divisions, departments, districts, etc.) and use these groupings to create relationships within the organization. With YOUnite these groupings are called zones.

Introduction

A zone refers to a collection of systems/applications owned by groups inside of an organizations. Zones are defined within YOUnite by the Administrator for each zone. Zones act as a boundary for which permissions and data governance may be defined so that an organization can control what data is accessible between the different zones within the organization. All resources within the YOUnite Data Fabric belong to a zone and some resources, such as users, can belong to multiple zones. Each zone has at a minimum two Zone roles: a Zone Admin and a Zone Data Steward.

Permissions vs Data Governance ACLs

When discussing zones it’s important to understand the distinction between permissions and data governance ACLs.

  • Permissions grant access to resources to users and/or groups in the YOUnite Data Fabric. Permissions are applied to users and/or services that consume the YOUnite API.

  • ACLs control the flow of inbound and outbound data events to and from adaptors (see the Governance page for more detailed ACL descriptions). ACLs are applied to a zone.

Zones

image

Zones are associated with each other in a hierarchical structure with parent, child, and sibling zones. 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

Zone Characteristics

Zones typically have the following characteristics:

  • One or more users responsible for general zone management (Zone Admins).*

  • One or more users responsible for the data, data domains, and data governance for the zones they are responsible for (Zone Data Stewards).*

  • Named sets of permissions that can be assigned to a user (Roles).

  • Named sets of roles that can be assigned to a user (Groups).

  • Zero, one, or more adaptors that map entities stored in external systems (such as databases) to Federated data domains (managed by the Zone Data Steward).

  • Data Governance rules, known as ACLs, that define what types of data events are allowed to flow into and out of the zone and its adaptors (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.

*NOTE: The Zone Admin and Zone Data Steward can be the same user.

The Root Zone

Upon initial deployment, YOUnite creates a zone called root. All subsequently-created zones are subordinate to the root zone.

In addition, two super-users are defined: admin (Root Admin) and dgs (Data Governance Steward). Apart from their super-user roles, these two users are also the Zone Admin and Zone Data Steward of the root zone, respectively. See Managed Roles.

Note
 The UUID of the root zone is always: 6c5a754b-6ce0-4871-8dec-d39e255eccc3.
image

Zones

After the root zone creation, child zones are created by the Zone Admin, or another user who has been delegated that permission.

On creation, new zones inherit the Zone Admin and Zone Data Steward from their parent zone.

Users

image

A user is a person or service that has access to resource(s) in a zone. A user is granted access to resource(s) either by being added to a group or by being assigned to specific roles.

Groups

image

A group is a collection of users in a zone. A group will have one or more roles associated with it and users can belong to more than one group.

Roles

image

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

There are two different kinds of roles:

  • Managed Roles that manage system permissions and features. These cannot be changed.

  • Custom Roles that are defined by the Zone Admin or Zone Data Steward.

Managed Roles

Managed roles are pre-defined roles that are integral to the functionality and permissions structure of YOUnite and cannot be modified. YOUnite has several managed roles:

  • Root Admin (super user)

  • Data Governance Steward (super user)

  • Zone Admin

  • Zone Data Steward

  • Base Permissions (required for using the YOUnite User Interface)

  • Notifications Server (special permissions granted to the YOUnite Notifications Service)

Root Admin and Data Governance Steward

The Root Admin and Data Governance Steward are super-user roles that can manage resources not associated with a specific zone.

Root Admin:

  • Manages user login information and update the active status of a user account.

  • Manages custom adaptor types.

  • Can view any user’s effective permissions.

Data Governance Steward:

  • Manages domains and domain versions.

  • Manages custom adaptor types.

  • Can view a zone’s adaptor preferences.

  • Can view any user’s effective permissions.

Zone Admin and Zone Data Steward

The Zone Admin and Zone Data Steward perform similar roles to the Root Admin and Data Governance Steward, but only for the zone they are given permission. As managers of the zone, they are also able to delegate any of their permissions to other users.

image
image

Zone Admin:

  • Monitors but does not create the adaptors in a zone.

  • Creates child zones.

  • Manages users, groups and roles in the zone.

  • May assign any of these permissions to other users in the zone.

Zone Data Steward:

  • Manages adaptors in the zone.

  • Manages users, groups and roles in the zone.

  • Manages inbound and outbound data governance ACLs.

  • Manages data issues and data event exceptions in the zone.

  • Can view metadata about all Data Records.

  • Can view all domains and domain versions.

  • May assign any of these permissions to other users in the zone.

Note
 Regardless of their level of permissions, any user with permission to assign roles or groups to another user MAY NOT assign permissions to that user that they do not themselves have. See Restrictions on Management of Users, Roles, Groups and Permissions.

Restrictions on Management of Users, Groups and Roles

Any user with permission to manage users, groups and/or roles (this includes the Zone Admin and Zone Data Steward) is subject to the following conditions:

  • A user cannot create a role that contains permissions that the user does not itself have.

  • A user cannot assign a user to a role that the user itself is not assigned to.

  • A user cannot assign a user to a group that the user itself is not assigned to.

image
image

See the YOUnite Server API documentation for more specific on roles.

Permissions

image

YOUnite users can be granted access to resources by setting appropriate permissions. Permissions do not stand on their own but are grouped into Roles (which are explained below). Permissions are managed by the Zone Admin, Zone Data Steward and/or other users that have been given control over a zone’s permissions. Think of permissions as being grouped together into Roles.

Permissions are broken out into four properties:

  1. Resource: The name of the resource.

  2. Resource URI: A unique URI that points to a specific resource, or a resource pattern with wildcards. The * wildcard indicates the given resources and all ancestors (ie the child resource and children of that child, etc). The ? wildcard indicates direct children of that resource, but not their children. The resource URI directly corresponds to the API endpoint that will be queried.

  3. Actions: These are the actions the user can perform on the resource. They include GET, PUT, POST, DELETE, PATCH (and ALL). These actions directly correspond to the REST actions that can be performed on the Resource URI.

  4. Resource Description: A brief description of the action as it applies to the Resource URI (See YOUnite Server API documentation).

The complete list of all permissions can be found on the Permissions Reference.

How permissions are applied to UI components can be found in the link: UI Permissions guide.

Permission Examples

In the examples below a user is:

  • Granted read-only (GET) access to all data domains

  • Granted read-only (GET) access to all versions of all data domains

  • Granted full access to the zone with UUID 662aa007-66a4-4d5a-8dca-a5cfa70b6284

  • Granted access to read and update (but not delete) all adaptors for the zone with UUID 662aa007-66a4-4d5a-8dca-a5cfa70b6284 PLUS read and update all child resources, plus their children, etc.

RESOURCE URI

GET

PUT

POST

DELETE

/domains/?

YES

NO

NO

NO

/domains/?/versions/?

YES

NO

NO

NO

/zones/662aa007-66a4-4d5a-8dca-a5cfa70b6284

YES

YES

YES

YES

/zones/662aa007-66a4-4d5a-8dca-a5cfa70b6284/adaptors/*

YES

YES

YES

NO

Effective Permissions

In a 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:

image

Data Access Rules

image

Data access rules define the permissions a user has to search for and/or assemble Data Records.

See Accessing Data Records for more information.

Managing Zones, Users, Groups, Roles, Permissions and Data Access Rules in the YOUnite User Interface

See YOUnite User Interface: Zones, Users, Groups, Roles, Permissions and Data Access Rules

Managing Zones, Users, Groups, Roles, Permissions and Data Access Rules with API Requests

See YOUnite API documentation for specifics on each API call.