1. The CO Person Object
People are represented in COmanage by a CO Person object. Some information is stored in this object, and it is connected to several other types of useful objects.
The attributes (information) stored in the CO Person object typically includes
- List of names
- List of identifiers
- List of email addresses
- The virtual organization or collaboration of which the person is a part
- The person’s status within that organization or collaboration
- Minimal information about the person including the person’s time zone, date of birth, and list of physical addresses.
This object also is connected to several other structural items that we will talk about in this lesson, including
- External Representations - representations of the person in other contexts outside of COmanage (including real life!) These representations include attributes and information about the person related to the other context. Each CO Person must have at least one of these, though multiple are allowed.
- Roles - the roles that the person assumes within your organization.
- Group Memberships - membership in a specific COmanage organizational object called a CO Group . We will learn more about CO Groups in a later lesson.
- Authenticators - methods for the person to sign into Services
CO Person status
Each CO Person object has a status attached to it. This status is a calculated value based on the person’s status in each of the Roles that the person has assumed in your organization or collaboration. We will review the calculation method when we talk about Roles. Status can be changed manually, or can change automatically based on conditions that you may set, or by workflows that you put in place.
The status value will affect what someone is able to do, including affecting what information is shared with external systems for access and resource provisioning. We will review how status affects provisioning when we talk about provisioning in a later lesson.
Below is a list of the available statuses.
Active Statuses
- Active: Person or Role is an active member of the organization or collaboration
- GracePeriod: Primary association with the organization has ended, but services have not yet been deprovisioned
Expired Statuses
- Suspended: Association with the organization has been (manually) temporarily suspended
- Expired: Valid through date has been reached
Invitation Statuses
- Approved
- PendingApproval: The enrollment flow petition is pending approval
- Confirmed
- PendingConfirmation: An invitation or email confirmation was sent via an enrollment flow
- Invited: An invitation was sent via default enrollment
- Pending
- Denied: The enrollment flow petition was denied
- Declined: The invitation sent via default enrollment was declined
- Deleted
- Duplicate: The record is a duplicate of another
About name attributes
Each CO Person object must include the person’s name. CO Person objects can have more than one name, but exactly one of the names must be designated as the primary name. Names can be encoded in any one of several languages / character sets.
About identifier attributes
The ultimate goal of identifiers is to facilitate application integration. In COmanage, each CO Person may be associated with any number of identifiers. They can be important when provisioning services to CO Persons .
We recommend that you configure at least one identifier for each CO Person to represent the person within COmanage. While it is possible to manually assign identifiers, we suggest that you allow COmanage to automatically assign these identifiers. You are able to configure what these identifiers will look like. We will review how to do this in a later lesson.
About email address attributes
COmanage can track email addresses. Email addresses can be verified from within COmanage (which we will not review during this workshop). Email addresses can also be used for mailing lists using the mailman provisioner (which we will review, time allowing.)
When storing email addresses, more than one can be associated with the CO Person , and can contain a type to help distinguish the conditions under which to use each. For example,
- official - the address to render in a directory entry, especially for use in a “To:” or “Cc:” field. LDAP attribute: mail
- personal - Alternate addresses to accept for mail delivery or forwarding. LDAP attribute: mailAlternateAddress
- delivery - the delivery location (e.g., mailbox). LDAP attribute: mailForwardingAddress
- forwarding - Address to forward mail to, perhaps if there is no delivery address, or an official or personal address is not functioning. LDAP attribute: mailForwardingAddress
About physical address attributes
This information is not used by COmanage, but since it is handy to have physical address information in your registry (for example, to share with your organization’s directory), it is included. Any number of physical addresses may be associated with a CO Person object.
Hands on - Starting our person model
As we build our understanding of how people are modeled in COmanage, we will use the Workshop Examples.
We will break you into breakout groups of 3-4 people for 10 min. For each of the three use cases, discuss how the different attributes of the CO Person object might be used. What kind of information would be useful to have for each of the people in the use cases? Where does this information generally come from?
Record your insights on the Etherpad.
[10 min]
Terminology & resources
See resources and definitions for COmanage-specific terminology in this lesson.