Skip to content
Permalink
Browse files

Updates from feedback

  • Loading branch information...
lpaglione
lpaglione committed Nov 12, 2019
1 parent 7c3e625 commit dd507fca7b00bc07530aba7f64004e05473f5d9d
@@ -24,20 +24,19 @@ People are represented in COmanage by a `CO Person`:gear: object. Some informati

The attributes (information) stored in the `CO Person`:gear: object typically includes

* The organization or collaboration of which the person is a part (in the form of an identifier)
* 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 preferred time zone and date of birth, list of physical addresses.
* Minimal information about the person including the person's time zone, date of birth, and list of physical addresses.
* List of names
* List of identifiers
* List of email addresses
* 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`:gear: 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 :gear" `CO Group`. We will learn more about :gear" `CO Groups` in a later lesson.
* **Authenticators** - methods for the person to sign into COmanage
* **Authenticators** - methods for the person to sign into Services

---

@@ -47,40 +46,44 @@ Each `CO Person`:gear: object has a status attached to it. This status is a calc

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 table of the available statuses _< NOTE: This list should be simplified somehow - some of these statuses aren't really used for CO person, but are interim status during the enrollment flow - should include only the 'stable' status that a CO Person remains in for longer durations. For the others, we can allude to them, and explain them more fully where they are actually used. >_

Preference | Status | Description
---------- | ------ | -----------
1 | Active | Person or Role is an active member of the organization or collaboration
2 | GracePeriod | Primary association with the organization has ended, but services have not yet been deprovisioned
3 | Suspended | Association with the organization has been (manually) temporarily suspended
4 | Expired | Valid through date has been reached
5 | Approved |
6 | PendingApproval | The enrollment flow petition is pending approval
7 | Confirmed |
8 | PendingConfirmation | An invitation or email confirmation was sent via an enrollment flow
9 | Invited | An invitation was sent via default enrollment
10 | Pending |
11 | Denied | The enrollment flow petition was denied
12 | Declined | The invitation sent via default enrollment was declined
13 | Deleted |
14 | Duplicate | The record is a duplicate of another
Below is a list of the available statuses.

**Active Statuses**

1. Active: Person or Role is an active member of the organization or collaboration
2. GracePeriod: Primary association with the organization has ended, but services have not yet been deprovisioned

**Expired Statuses**

3. Suspended: Association with the organization has been (manually) temporarily suspended
4. Expired: Valid through date has been reached

**Invitation Statuses**

5. Approved
6. PendingApproval: The enrollment flow petition is pending approval
7. Confirmed
8. PendingConfirmation: An invitation or email confirmation was sent via an enrollment flow
9. Invited: An invitation was sent via default enrollment
10. Pending
11. Denied: The enrollment flow petition was denied
12. Declined: The invitation sent via default enrollment was declined
13. Deleted
14. Duplicate: The record is a duplicate of another

# About name attributes

Each `CO Person`:gear: object must include the person's name. `CO Person`:gear: 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

_< NOTE: Laura wrote this section, but isn't sure about her understanding of identifiers for CO Person. From the documentation it sounds like the recommendation is to have one CO Person identifier that is auto assigned, and for this identifier to be used for provisioning to at least some kinds of services rather than tying that provisioning to an org identity (like eppn) that may change if affiliation does. BUT... this may be totally wrong. >_

Identifiers allow for unique identification. In COmanage, each `CO Person`:gear: may be associated with [an?] identifier[s?]. [These identifiers | The identifier] can be important when provisioning services to `CO Persons`:gear:.
The ultimate goal of identifiers is to facilitate application integration. In COmanage, each `CO Person`:gear: may be associated with any number of identifiers. They can be important when provisioning services to `CO Persons`:gear:.

We recommend that you configure at least one identifier for each `CO Person`:gear: 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.

# About email address attributes

COmanage can track email addresses, though it does very little with them directly. 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.)
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`:gear:, and can contain a type to help distinguish the conditions under which to use each. For example,

@@ -91,7 +94,7 @@ When storing email addresses, more than one can be associated with the `CO Perso

# About physical address attributes

This information is not used by COmanage, but since it is handy to have physical address information in your registry, it is included. Any number of physical addresses may be associated with a :gear" `CO Person` object.
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 :gear" `CO Person` object.

---

@@ -18,14 +18,13 @@ nextEpisodeName: "3. Memberships"
nextEpisodeURL: "/_episodes/03-memberships.md"
---

# 2. The OrgIdentity Object
# 2. The Org Identity Object

Because people in COmanage are represented by `CO Person`:gear: objects, it is helpful to link these objects to _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. In COmanage, these external representations are captured in `Org Identity`:gear: objects, and are connected to _Sources_ or _Systems of Record_.

The attributes (information) stored in `Org Identity`:gear: objects typically includes

* Link to `CO Person`:gear: object
* Status
* Personal information about the person
* Date of birth
* affiliation (eduPerson)
@@ -38,8 +37,8 @@ The attributes (information) stored in `Org Identity`:gear: objects typically in

This object also is connected to several other structural items that we will talk about in this lesson, including

* **Source Information** - represented by an `Identity Source`:gear: object, this item contains details about how the source should be processed and the data gathered from the representation of the person at the source.
* **Cached Source Information** - represented by an `Identity Source Records`:gear: object, this item connects the `Identity Source`:gear: to the `Org Identity`:gear:, and is also used to cache data in COmanage from sources so that they are readily available.
* **Source Information** - represented by an `Organizational Identity Source`:gear: object, this item contains details about how the source should be processed and the data gathered from the representation of the person at the source.
* **Cached Source Information** - represented by an `Organizational Identity Source Records`:gear: object, this item connects the `Organizational Identity Source`:gear: to the `Org Identity`:gear:, and is also used to cache data in COmanage from sources so that they are readily available.

---

@@ -49,16 +48,13 @@ These lists of items are handled similarly to how they are used for `CO Person`:

# About identifier attributes

_< NOTE: Laura wrote this section, but isn't sure about her understanding of identifiers for Org Identity. The information here may be totally wrong. >_

`Org Identity`:gear: objects also use identifiers. The identifiers can be one of several different types
`Org Identity`:gear: objects also use identifiers. The identifiers can be one of several different types, with the first two being the most common. These identifiers are provided by the Source.

* eppn: eduPersonPrincipalName
* eptid: eduPersonTargetedID
* mail: RFC 4524
* openid: OpenID
* uid: RFC 4519 uidObject (previously userid)
* Or an extended type that is specific to the source related to the `Org Identity`:gear:

## Identifiers for authentication

@@ -74,10 +70,10 @@ The `Org Identity`:gear: object is related to the source where its information c

* for auditing where information about a person came from
* for syncing with external systems to get the most up-to-date information
* to connect for performing actions that may happen outside of COmanage, for example, federated authentication.
* to connect with actions that may happen outside of COmanage, for example, federated authentication.
* to provide information about the person provisioning access and privileges to external ("outbound") systems.

COmanage has built-in capability to consume data and attributes from many of these sources, and can be extended to support additional sources. This information is managed through `Identity Source`:gear: objects and their COmanage-cached versions, `Identity Source Record`:gear: objects.
COmanage has built-in capability to consume data and attributes from many of these sources, and can be extended to support additional sources. This information is managed through `Organizational Identity Source`:gear: objects and their COmanage-cached versions, `Organizational Identity Source Record`:gear: objects.

Systems of Record (external sources) can be from anywhere. Common ones include LDAP servers, REST APIs, SQL databases, flat files, and so on.

@@ -99,21 +95,21 @@ API-based sources (API) | Used to associate registered people with information f
# The Identity Source AND Identity Source Record Objects

## `Identity Source`:gear: Object
## `Organizational Identity Source`:gear: Object

Source attributes (information), once gathered, is stored in `Identity Source`:gear: Objects. These objects contain details about how the source information should be processed and data gathered from the representation of the person at the source.
Source attributes (information), once gathered, is stored in `Organizational Identity Source`:gear: Objects. These objects contain details about how the source information should be processed and data gathered from the representation of the person at the source.

The information stored in `Identity Source`:gear: objects typically includes:
The information stored in `Organizational Identity Source`:gear: objects typically includes:

* **Descriptive information** - A description of the source, and its status
* **Processing information** - information about what information should be synced and under what conditions, what do if there is mis-matched information, how to handle this source when searching, and what to store when caching the source (for example, as a hash of the information or the full source record)
* **Connection information** - which source type is connected, and identifiers for the person used at the source

In addition, specific data and attributes, customized for the source type, is attached to the `Identity Source`:gear: Object.
In addition, specific data and attributes, customized for the source type, is attached to the `Organizational Identity Source`:gear: Object.

## `Identity Source Records`:gear: Object
## `Organizational Identity Source Records`:gear: Object

Information from an `Identity Source`:gear: is connected to a `Org Identity`:gear: object via an :gear" `Org Identity Source Record` object. These objects are also used to cache data from sources so that they are readily available.
Information from an `Organizational Identity Source`:gear: is connected to a `Org Identity`:gear: object via an :gear" `Org Identity Source Record` object. These objects are also used to cache data from sources so that they are readily available.

In addition to the links to the related `Org Identity`:gear: and :gear" `Org Identity Source` objects, these objects also include information about when the data was last cached.

@@ -139,8 +135,8 @@ OBJECT | DESCRIPTION | Introduced in
------ | ----------- | -------------
`CO Person`:gear: | the representation of a person in COmanage | [CO310-01](/_episodes/01-COperson.md)
`CO Group`:gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons`:gear: | [[CO320-03](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/03-groups.md)
`Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | CO310-02 _(this session)_
`Identity Source Records`:gear: | COmanage's cached value of the values at the source | CO310-02 _(this session)_
`Organizational Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | CO310-02 _(this session)_
`Organizational Identity Source Records`:gear: | COmanage's cached value of the values at the source | CO310-02 _(this session)_

## Worksheets

@@ -50,8 +50,8 @@ OBJECT | DESCRIPTION | Introduced in
------ | ----------- | -------------
`CO Person`:gear: | the representation of a person in COmanage | [CO310-01](/_episodes/01-COperson.md)
`CO Group`:gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons`:gear: | [CO320-03](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/03-groups.md)
`Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | [CO310-02](/_episodes/02-orgIdentity.md)
`Identity Source Records`:gear: | COmanage's cached value of the values at the source | [CO310-02](/_episodes/02-orgIdentity.md)
`Organizational Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | [CO310-02](/_episodes/02-orgIdentity.md)
`Organizational Identity Source Records`:gear: | COmanage's cached value of the values at the source | [CO310-02](/_episodes/02-orgIdentity.md)

## Worksheets

@@ -37,18 +37,12 @@ Some groups for managing these permissions are created automatically when config
* **Admin groups** - for some component that you use to model your organization, a group will be created for each that will contain administrators for that organizational component. Members of this group will have permissions allowing them to manage the organizational component and the things attached to the organizational component. There is also a general **admins** group that contains all people who are an admin in any capacity.
* **Active Members group** - All people registered with an active status in COmanage will be included in this group. Members of this group will have permissions allowing them to do thing like signing into COmanage.

# Guest permissions

COmanage allows you to configure it to let people who are not fully registered (guests) to see some information stored on the platform (for example, a person directory or list of groups.) The platform also enables you to allow guests to create their own accounts (self enroll), for example, to join a group for a mailing list or to access specific resources. We will talk more about these capabilities in a later lesson about enrollment workflows.

# Self Service Permissions

COmanage allows certain attributes (information) to be managed by users directly.

## Attributes always available for self service

* `CO Person`:gear: NSF Demographic attributes (an optional COmanage component)
* `CO Person`:gear: Preferred Timezone
* `CO Group`:gear: Memberships (for open groups or groups owned by the CO Person) - _we will be talking about Groups in the next lesson._
* SSH Keys attached to a CO Person record - _we will be talking about authenticators and SSH Keys in a later lesson._

@@ -59,7 +53,7 @@ COmanage allows certain attributes (information) to be managed by users directly
* `CO Person`:gear: EmailAddress
* `CO Person Role`:gear: TelephoneNumber
* `CO Person`:gear: Identifier
* `CO Person`:gear: URL (as of v3.1.0)
* `CO Person`:gear: URL

_By default, these attributes are read only._

@@ -97,8 +91,8 @@ OBJECT | DESCRIPTION | Introduced in
------ | ----------- | -------------
`CO Person`:gear: | the representation of a person in COmanage | [CO310-01](/_episodes/01-COperson.md)
`CO Group`:gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons`:gear: | [CO320-03](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/03-groups.md)
`Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | [CO310-02](/_episodes/02-orgIdentity.md)
`Identity Source Records`:gear: | COmanage's cached value of the values at the source | [CO310-02](/_episodes/02-orgIdentity.md)
`Organizational Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | [CO310-02](/_episodes/02-orgIdentity.md)
`Organizational Identity Source Records`:gear: | COmanage's cached value of the values at the source | [CO310-02](/_episodes/02-orgIdentity.md)
`CO Person Role`:gear: | the representation of a person's role in COmanage. This object describe the person's role with certain collections of people within your organization or collaboration. These objects are attached to :gear: `CO Person` objects; there may be any number of Roles. | C0310-04 _(this session)_

## Worksheets
Oops, something went wrong.

0 comments on commit dd507fc

Please sign in to comment.
You can’t perform that action at this time.