Zones, Users, Groups, Roles and Permissions

Zones

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

Zone Characteristics

Zones have the the following characteristics:

• A person responsible for general zone management (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.
• Zero, one, or more adaptors that map entities stored in services to federated data domains.
• Controlled access to zone resources (controlled by the Zone Admin) with the exception of adaptor-associated data.
• Controlled access to the data entities associated with a zone's adaptors (controlled by the Zone Data Steward).
• Restricted out-bound and/or in-bound data shared with/from other zones (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 user called: mdmadmin. All subsequently-created zones are subordinate to the root zone.

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

Users

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). 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. He is the Zone Admin for the College District zone. Senor Jefe creates the "Central College" zone and assigns IT Admin Cece Jones's SSO ID to it. Cece Zones is the Zone Admin for the "Central College" zone and also has a new YOUnite User (cece@college_district.edu) created that is associated with the "Central College" zone:

If two more zone's are created and Cece's SSO ID is associated with them, her same YOUnite User name is used 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.

YOUnite User permissions are specific to the zone 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

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

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.

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, 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).

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. Permissions do not stand on their own but are grouped into Polices (which are explained below). Permissions are managed by the Zone Admin 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 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. )