diff --git a/_episodes/02-cous.md b/_episodes/02-cous.md index 6b21806..ef09e03 100644 --- a/_episodes/02-cous.md +++ b/_episodes/02-cous.md @@ -8,4 +8,38 @@ objectives: - "List the objectives" keypoints: - "List the key takeaways for the episode" ---- \ No newline at end of file +--- + +# CO Person Role Status + +As with the :gear: `CO Person` object, each :gear: `CO Person Role` object + +## Calculated status value + +Calculating the :gear: `CO Person` status from those of the :gear: `CO Person Role` object + +Each CO Person Role has a status attached to it and each CO Person has an overall status that is generally calculated as the "most preferred" of the attached CO Person Role statuses. Statuses represent various states in the identity lifecycle, and various statuses have specific meanings within COmanage. + +Status can be changed under various circumstances: + +* As part of Enrollment or Invitation. (Onboarding) +* As part of an Organizational Identity Source and Pipeline sync. +* Due to an Expiration Policy. (Offboarding) +* By updating CO Person Role validity dates. + * If a Role is in Pending status and the Valid From date is updated to be in the past, the Role will automatically change to Active status. + * If a Role is in Active status and the Valid From date is updated to be in the future, the Role will automatically change to Pending status. + * If a Role is in Expired status and the Valid Through date is updated to be in the future, the Role will automatically change to Active status. + * If a Role is in Active or Grace Period status and the Valid Through date is updated to be in the past, the Role will automatically change to Expired status. +* Manually. Note that manual changes will be overwritten when an automatic update would result in a different status. + +The status of a CO Person is generally calculated from the status of the CO Person Roles attached. This happens automatically under the following conditions: + +* When a CO Petition is approved/the Enrollee becomes active. +* When an Expiration Policy changes the status of a CO Person Role. +* When updating a CO Person Role Valid Through date causes the CO Person Role to become Active. +* When a Pipeline results in a status change. +* When a CO Person Role status is manually changed. + +The CO Person status is set to the "most preferred" status of the attached CO Person Roles. "Most preferred" is currently defined as the order in the table, below. In general, active statuses are most preferred, followed by expired statuses (since there may have been skeletal records provisioned that need to be maintained), followed by invitation statuses. + +CO Person and Person Role Records are passed to Provisioners based on their status, as indicated in the table, below. \ No newline at end of file diff --git a/_episodes/04-groups.md b/_episodes/04-groups.md index 69b7a93..90b58ce 100644 --- a/_episodes/04-groups.md +++ b/_episodes/04-groups.md @@ -167,4 +167,104 @@ Since v2.0.0: Prior to v2.0.0: * The members group holds all CO People within the CO. -* Groups of the form members:couname hold all CO People with a role in the specified COU. \ No newline at end of file +* Groups of the form members:couname hold all CO People with a role in the specified COU. + +# CO Email lists + +Email Lists are data structures that associate [CO Groups and Group Memberships](https://spaces.at.internet2.edu/display/COmanage/CO+Groups+and+Group+Memberships) with listservs. Email Lists are available as of Registry v3.1.0. + +Registry does not provide actual message delivery capabilities, but rather maintains metadata about lists in order to provision list management software using [Provisioner Plugins](https://spaces.at.internet2.edu/display/COmanage/Provisioning+From+Registry) that support Email List objects. Email List-aware provisioners include: + +* [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin) (not yet implemented, [CO-1439](https://bugs.internet2.edu/jira/browse/CO-1439)) +* [Mailman Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/Mailman+Provisioning+Plugin) + +Several groups can be attached to an Email List in order to define both list membership and roles for the list. The following are currently supported: + +* Members +* Administrators +* Moderators + +As an example, if you create a email list called "Researchers" and attach the CO Group "Biologists" as its members group, then any valid CO Person who is a member of Biologists will be subscribed to the Researchers list in the mailing list management software. The actual privileges assigned to members, administrators, and moderators are determined by the specific mailing list software. + +The list name will typically become the left hand side of the list's email address. + +## Email list data structure + +You can find the registry data model for CO mail lists in the [wiki: cm_co_email_lists](https://spaces.at.internet2.edu/display/COmanage/cm_co_email_lists) + +# Registry services + +As of v2.0.0, COmanage Registry supports a concept of CO Services. A CO Service represents a service or application that a CO Person has access to by participating in the collaboration. While access to the service is likely controlled by Registry managed attributes, the service itself is not accessed as part of Registry. Instead, CO Services act as inventory or catalog of available services, rendering a list of available services on a per CO Person basis. + +CO Services are registered by a CO Administrator via the Configuration >> Services menu, and are made visible to users via both the Services menu (v2.0.x only; visible only after the first CO Service is registered) and the Service Portal (available in the main menu). CO Service attributes include + +* **CO Group**: Access to this service is available only to members of this group. Note the application is ultimately responsible for its own access control. +* **Service URL**: The URL of the service. +* **Logo URL**: The URL for an image that represents this service. If you'd like to serve these locally from your Registry server, see [Publishing Images and Other Media](https://spaces.at.internet2.edu/display/COmanage/Publishing+Mostly+Static+Public+Content). +* **Contact Email**: The email address of a contact responsible for managing the service. +* **Entitlement URI**: The [entitlement URI](http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonEntitlement) associated with this service. Used (eg) by the [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin). +* **Visibility**: Who can see this CO Service entry. Note that administrators are not treated specially – they will only see Services in the menu and portal for which they have associated eligibilities. To see the full list of services, administrators can use the configuration menu. + * **CO Admin**: Only CO Administrators within the CO can see this service + * **CO Group Member**: Only members of the associated CO Group can see this service + * **CO Person**: Any CO Person within the CO can see this service + * **Unauthenticated User**: Anyone can see this service +* **COU**: COU this CO Service is associated with. Service Portals will be available (in the main menu) for each COU with attached services. If set, this service will not be visible in the CO's Service Portal. Available since Registry v3.1.0. +* **Service Identifier Type**: Used to indicate which type of [Identifier](https://spaces.at.internet2.edu/display/COmanage/cm_identifiers) is to be used with this Service. Available since Registry v3.2.0. +* **Short Label**: Primarily intended for use with the [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin), a short label for the service that can be used when attribute options are enabled. Available since Registry v3.2.0. + +If at least one CO Service is configured with Unauthenticated User visibility, then the Service Portal will be publicly accessible. Otherwise, only members of the CO can see the Service Portal. + +> The Service Portal can be rendered within [Registry Dashboards](https://spaces.at.internet2.edu/display/COmanage/Registry+Dashboards) by using the [Services Dashboard Widget](https://spaces.at.internet2.edu/display/COmanage/Services+Widget+Plugin). + +## CO Services data structure + +You can find the registry data model for CO mail lists in the [wiki: cm_co_services](https://spaces.at.internet2.edu/display/COmanage/cm_co_services) + +---- + +# Administrator Roles + +COmanage Registry defines three types of administrators. + +## Platform (CMP) Administrators _(Also called Registry Admin in the documentation)_ + +Platform Administrators are effectively super users, with the ability to perform almost all operations on the platform. (Platform Administrators cannot execute enrollment flows for COs unless authorized by the enrollment flow.) + +Platform Administrators are configured by [adding the appropriate Organizational Identity](https://spaces.at.internet2.edu/display/COmanage/Default+Registry+Enrollment) to the COmanage CO, and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the COmanage CO. + +The first user added as part of the [Registry Setup Script](https://spaces.at.internet2.edu/display/COmanage/Registry+Installation+-+Registry+Setup+Script) is automatically configured to be a Platform Administrator. + +## Collaboration (CO) Administrators + +Collaboration Administrators are super users _within a CO_. Collaboration Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the CO. + +CO Administrators can manage any CO Group within their CO. + +## Unit (COU) Administrators + +Collaboration Administrators with sophisticated administrative requirements may optionally define Unit Administrators. Unit Administrators have limited privileges within the CO, generally related to the ability to enroll and manage populations within the CO Unit (COU). + +Unit Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the _CO:COU:COU-Name:admins_ group (v2.0.0 and later) or _admin:COU-Name_ group (prior to v2.0.0) within the CO. + +COU Administrators can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU). + +## System Administrators + +System Administrators have privileges that enable them to maintain the COmanage application. These capabilities include the ability to provision cluster resources (for example, hardware, virtual machines, etc), Register and maintain IP Addresses, administer application upgrades, manage and conduct operating system upgrades and conduct backups. + + + +## Permissions + +Generally, Registry permissions are based on the type of user a person is. These types are generally based on group memberships, and include administrative users as well as non-administrative users. + +Permission | CMP Administrator | CO Administrator | COU Administrator | Group Owner | Group Member | CO Person | Anonymous +---------- | ----------------- | ---------------- | ----------------- | ----------- | ------------ | ------ | --------- +Configure COmanage platform | (tick) | | | | | | +Configure CO | (tick) | (tick) | | | | | +Start Enrollment | | (tick) | If configured | | If configured | If configured | If configured +Manage CO Person | (tick) | (tick) | (tick) within COU | | | See [Self Service Permissions](https://spaces.at.internet2.edu/display/COmanage/Self+Service+Permissions) +Create Group | (tick) | (tick) | | | | (tick) | +Manage Group | (tick) | (tick) | | (tick) | | | +Add Self To Open Group | | | | | | (tick) | +Remove Self From Group | | | | | (tick) | | \ No newline at end of file diff --git a/files/handouts/CO320-ModelingOrgs.pdf b/files/handouts/CO320-ModelingOrgs.pdf new file mode 100644 index 0000000..7ef2339 Binary files /dev/null and b/files/handouts/CO320-ModelingOrgs.pdf differ