Page tree
Skip to end of metadata
Go to start of metadata

Registry models are built on a basic CRUD model, however Registry implements additional logic in many places. This document provides a "contract" for these application (or "domain" or "business") rules that follows Semantic Versioning (beginning with Registry v5.0.0). ie: Rules documented here will not change in a backward-incompatible way between minor Registry versions.

General Model Rules (GMRs)

  1. Once an entity is created within a CO, it cannot be moved to another CO.
  2. Foreign keys from one entity to another cannot cross COs.
  3. The Primary Link key for an object cannot be changed once set. (For example, an object that populates person_id cannot subsequently populate external_identity_id instead.)
  4. Timestamps (regardless of which time and/or date components are significant) are stored in the database as UTC.

API User

  1. API Users created in the COmanage CO (CO #1) have full access to the Registry API.
  2. API Users created in other COs may be privileged, in which case they have full access to the Registry API for that CO, or unprivileged, in which case access most be contextually granted.
  3. For namespacing purposes, API Users are named with a prefix consisting of the string co_#. (the letters co, an underscore, the numeric ID of the CO, and a dot). API usernames must be unique across the entire platform.
  4. API Keys for API Users cannot be directly set, only generated.

Authentication Event

  1. Authentication Events are tracked by authenticated identifiers, and therefore are not bound to any specific CO.
  2. A CO Administrator may view all Authentication Events associated with any authenticated (login) Identifier associated with any Person within their CO, even if the Authentication Event was intended for access to another CO.
  3. A Privileged CO API User may retrieve all Authentication Events associated with any authenticated (login) Identifier associated with any Person within its CO, even if the Authentication Event was intended for access to another CO.
  4. Because Authentication Event records are not part of any CO, they are not deleted under circumstances such as the deletion of a CO.

CO

  1. Deleting a CO will cause a hard delete of all CO related data.
  2. The CO named COmanage cannot be rename, deleted, or suspended.
  3. Two COs cannot share the same name.
  4. Duplicating a CO will duplicate configuration related objects (such as COUs, Groups, and Enrollment Flows) but not data related objects (such as People and Group Memberships).
  5. A CO cannot be deleted if it is in Active status.
  6. When a new CO is created, the special groups associated with the CO will also be created.
  7. If a CO is renamed, the special groups associated with the CO will also be renamed.

COU

  1. A COU may not be deleted if it has any members (ie: People with a Person Role with the specified COU).
  2. A COU may not be deleted if it has any children.
  3. Two COUs within the same CO cannot share the same name.
  4. When a COU is created, the special groups associated with the COU will also be created.
  5. If a COU is renamed, the special groups associated with the COU will also be renamed.

Group

  1. Two Groups within the same CO cannot share the same name.
  2. A Group cannot be set to Suspended if it is nested into a Target Group or is a Target Group for a nesting.
  3. A Group cannot be deleted if it is nested into a Target Group or is a Target Group for a nesting.

Group Member

  1. A Person cannot be given two manually created GroupMember records for the same Group. A Person can have more than one GroupMember record for the same Group via other mechanisms, such as Group Nestings, or External Identity Sources connected to Pipelines.

Group Nesting

  1. Only Active Groups may be nested into a Target Group.
  2. A Group may not be nested into itself.
  3. A Group may not be nested into an Automatic Group.
  4. A Group may not be nested into the same Target Group more than once, either directly or indirectly.
  5. Group Nestings may not loop.

Identifier

  1. The login flag may only be set on an Identifier if it is attached to a Person.

Name

  1. Exactly one Name for each Person and External Identity must be designated as Primary at all times. The Primary Name cannot be deleted, another Name must be designated Primary first.
  2. If a display name value is provided for any Name, it will be used within Registry whenever a full name representation of that Name is required.
  3. If a full name is constructed from the various Name components, by default the components will be assembled as givenmiddlefamilysuffix. However, for Names with a language set to hujakoza-Hans, or za-Hant, the components will be assembled as familygiven.
  4. Each Person and External Identity must have at least one Name.

Person

  1. When a Person is associated with a CO with any status other than Archived, the Person is added to the CO's All Members Group. If the Person is deleted from the COU, or the Person's status is set to Archived, the Person is removed from the CO's All Members Group.
  2. When a Person is in Active or Grace Period status, the associated Person is added to the CO's Active Members Group. If the Person is set to any other status or is deleted from the , the Person is removed from the CO's Active Members Group.

Person Role

  1. When a Person Role is associated with a COU with any status other than Archived, the associated Person is added to the COU's All Members Group. If the Person Role is disassociated from the COU, or the Person Role status is Archived, the associated Person is removed from the COU's All Members Group.
  2. When a Person Role is in Active or Grace Period status and is associated with a COU, the associated Person is added to the COU's Active Members Group. If the Person Role is set to any other status or is disassociated from the COU, the associated Person is removed from the COU's Active Members Group.

Plugin

  1. Plugins must be uniquely named.
  2. Plugins installed in the core directory cannot be disabled.
  3. Plugins installed in the available directory are optional, and must be enabled prior to use.
  4. Plugins installed in the local directory are deployment specific, and must be enabled prior to use.
  5. If Plugins with the same name are installed in multiple locations, the resolution precedence is (1) core, (2) available, (3) local.
  6. Plugin schemas, if defined, are applied to the database for active Plugins only.
  7. If a Plugin is suspended, its associated database schema is not removed automatically.
  8. A Plugin cannot be suspended or deleted if it is in use (referenced in a configuration object).
  9. When a Plugin is instantiated, a skeletal record of the Entry Point Model is created, holding only a foreign key to the parent Pluggable Model. Validation and Application Rules are not executed when this record is created.
  10. If a Pluggable Model is deleted, the Entry Point Model associated with the Pluggable Model is also deleted.
  11. The Plugin Registry is refreshed upon loading of the Plugin Configuration page by the Platform Administrator.

Type

  1. When a new CO is created, the default Types will be instantiated into the CO. Afterwards, available Types are only updated by administrator action.
  2. A Type cannot be deleted once it has been used by at least one Registry object, even if that object is subsequently deleted.
  3. A Suspended Type can not be assigned to new Registry objects, but existing objects already referencing it will not be changed.
  • No labels