diff --git a/_episodes/01-COperson.md b/_episodes/01-COperson.md index 27fbf1c..04a3856 100644 --- a/_episodes/01-COperson.md +++ b/_episodes/01-COperson.md @@ -12,9 +12,9 @@ keypoints: # 1. The CO Person -People are represented in COmanage by a :gear: `CO Person` object. Some information is stored in this object, and it is connected to several other types of useful objects. +People are represented in COmanage by a `CO Person` :gear: object. Some information is stored in this object, and it is connected to several other types of useful objects. -The information stored in the :gear: `CO Person` object typically includes +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 person's status within that organization or collaboration @@ -26,7 +26,7 @@ The information stored in the :gear: `CO Person` object typically includes 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 :gear: `CO Person` must have at least one of these, though multiple are allowed. +* **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 @@ -35,7 +35,7 @@ This object also is connected to several other structural items that we will tal # CO Person status -Each :gear: `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. +Each `CO Person` :gear: 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. @@ -58,30 +58,30 @@ Preference | Status | Description 13 | Deleted | 14 | Duplicate | The record is a duplicate of another -# About names +# About name attributes -Each :gear: `CO Person` object must include the person's name. :gear: `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. +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 identifiers +# 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 :gear: `CO Person` may be associated with [an?] identifier[s?]. [These identifiers | The identifier] can be important when provisioning services to :gear: `CO Persons`. +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:. -We recommend that you configure at least one identifier for each :gear: `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 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 addresses +# 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.) -When storing email addresses, more than one can be associated with the :gear: `CO Person`, and can contain a type to help distinguish the conditions under which to use each. For example, +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, * **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 addresses +# 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. @@ -91,7 +91,7 @@ This information is not used by COmanage, but since it is handy to have physical ![Interactive system activity](../assets/img/hands-on-keyboard.png) -As we build our understanding of how people are modeled in COmanage, we will use people in your organization as examples. In your printed packet, there are sheets for [ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf). +As we build our understanding of how people are modeled in COmanage, we will use people in your organization as examples. In your printed packet, there are sheets for [ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf). Think of at least three people in your organization that you can use as examples. The three that you choose should assume different roles in your organization or collaboration. Maybe they have different levels of authority, have access to different kinds of systems or services, form and manage their own groups. One of the people you choose may even work for a different organization, though collaborates with individuals in your organization. @@ -107,14 +107,14 @@ Once you have thought about who you will use as your examples, write their names OBJECT | DESCRIPTION ------ | ----------- -:gear: `CO Person` | the representation of a person in COmanage -:gear: `CO Group` | a specific COmanage organizational structure for representing certain collections of :gear: `CO Persons` +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: ## Worksheets WORKSHEET | DESCRIPTION --------- | ----------- -[ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage +[ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage ## Slides diff --git a/_episodes/02-orgIdentity.md b/_episodes/02-orgIdentity.md index 048cf6d..7195e51 100644 --- a/_episodes/02-orgIdentity.md +++ b/_episodes/02-orgIdentity.md @@ -12,64 +12,64 @@ keypoints: # 2. The OrgIdentity Object -Because people in COmanage are represented by :gear: `CO Person` 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 :gear: `Org Identity` objects, and are connected to _Sources_ or _Systems of Record_. +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 information stored in :gear: `Org Identity` objects typically includes +The attributes (information) stored in `Org Identity` :gear: objects typically includes -* Link to :gear: `CO Person` object +* Link to `CO Person` :gear: object * Status * Personal information about the person * Data of birth * affiliation (eduPerson) * source organization, department, & title * Validity dates: from and through -* List of names - Same as for :gear: `CO Person` +* List of names - Same as for `CO Person` :gear: * List of identifiers -* list of email addresses - Same as for :gear: `CO Person` -* list of physical addresses - Same as for :gear: `CO Person` +* list of email addresses - Same as for `CO Person` :gear: +* list of physical addresses - Same as for `CO Person` :gear: This object also is connected to several other structural items that we will talk about in this lesson, including -* **Source Information** - represented by an :gear: `Identity Source` 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 :gear: `Identity Source Records` object, this item connects the :gear: `Identity Source` to the :gear: `Org Identity`, and is also used to cache data in COmanage from sources so that they are readily available. +* **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. --- -# About names, email addresses and physical addresses +# About name, email address and physical address attributes -These lists of items are handled similarly to how they are used for :gear: `CO Person` objects. Because of their similarity, we won't review them in this section. +These lists of items are handled similarly to how they are used for `CO Person` :gear: objects. Because of their similarity, we won't review them in this section. -# About identifiers +# 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. >_ -:gear: `Org Identity` 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 * 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 :gear: `Org Identity` +* Or an extended type that is specific to the source related to the `Org Identity` :gear: ## Identifiers for authentication -Identifiers attached to :gear: `Org Identity` objects can potentially be used for signing into COmanage. A flag set on the identifier will indicate if it is used for sign in. +Identifiers attached to `Org Identity` :gear: objects can potentially be used for signing into COmanage. A flag set on the identifier will indicate if it is used for sign in. --- Now we'll talk about sources - information from external systems - and how they are captured and used in COmanage. -# The relationship between :gear: `Org Identity` objects and **sources** +# The relationship between `Org Identity` :gear: objects and **sources** -The :gear: `Org Identity` object is related to the source where its information came from. Often the source is from an external system, like LDAP, an authentication system, ORCID or even a CSV file. COmanage keeps track of this source for several reasons: +The `Org Identity` :gear: object is related to the source where its information came from. Often the source is from an external system, like LDAP, an authentication system, ORCID or even a CSV file. COmanage keeps track of this source for several reasons: * 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 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 :gear: `Identity Source` objects and their COmanage-cached versions, :gear: `Identity Source Record` 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 `Identity Source` :gear: objects and their COmanage-cached versions, `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. @@ -93,21 +93,21 @@ API-based sources (API) | Used to associate registered people with information f ## :gear: Identity Source Object -Source information, once gathered, is stored in :gear: `Identity Source` 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 `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 :gear: `Identity Source` objects typically includes: +The information stored in `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 :gear: `Identity Source` Object. +In addition, specific data and attributes, customized for the source type, is attached to the `Identity Source` :gear: Object. ## :gear: Identity Source Records Object -Information from an :gear: `Identity Source` is connected to a :gear: `Org Identity` 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 `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 :gear: `Org Identity` and :gear" `Org Identity Source` objects, these objects also include information about when the data was last cached. +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. --- @@ -115,7 +115,7 @@ In addition to the links to the related :gear: `Org Identity` and :gear" `Org Id ![Interactive system activity](../assets/img/hands-on-keyboard.png) -Think about the sources outside of COmanage where you store information about the people you may be registering. Use the individuals that you wrote down on the [ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) worksheet to think of specific examples. +Think about the sources outside of COmanage where you store information about the people you may be registering. Use the individuals that you wrote down on the [ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf) worksheet to think of specific examples. In the **Org Identities** box, jot down one or more sources where there are representations for each of the people you have listed in the last exercise. All of the people you have listed may be represented in the same sources, or some may differ. Consider sources from systems, and also consider source like spreadsheet which may contain members of a project team. @@ -129,15 +129,15 @@ In the **Org Identities** box, jot down one or more sources where there are repr OBJECT | DESCRIPTION ------ | ----------- -:gear: `Org Identity` | the representation of a person in other contexts outside of COmanage -:gear: `Identity Source` | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID. -:gear: `Identity Source Records` | COmanage's cached value of the values at the source +`Org Identity` :gear: | the representation of a person in other contexts outside of COmanage +`Identity Source` :gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID. +`Identity Source Records` :gear: | COmanage's cached value of the values at the source ## Worksheets WORKSHEET | DESCRIPTION --------- | ----------- -[ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage +[ Modeling People :memo:](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage ## Slides @@ -145,7 +145,7 @@ To be included --- -NEXT SECTION: [3. About Attributes](/_episodes/03-attributes.md) +NEXT SECTION: [3. About Permissions](/_episodes/03-permissions.md) PREVIOUS SECTION: [1. The CO Person Object](/_episodes/01-COperson.md) diff --git a/_episodes/03-memberships.md b/_episodes/03-memberships.md new file mode 100644 index 0000000..fcbb0d2 --- /dev/null +++ b/_episodes/03-memberships.md @@ -0,0 +1,66 @@ +--- +title: "About Groups" +teaching: 0 +exercises: 15 +questions: +- "Question here" +objectives: +- "List the objectives" +keypoints: +- "List the key takeaways for the episode" +--- + +# 4. Memberships + +Understanding the the types of grouping that people in your organization or collaboration form is helpful when modeling your organization. We will be talking in depth about modeling your organization within COmanage in the next lesson, though it will be helpful for you to have some specific examples in mind when we do that. + +--- + +# Hands on - Considering how people are linked to your organization + +![Interactive system activity](../assets/img/hands-on-keyboard.png) + +Consider the people that you have been working with on your worksheet [ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf). How are these individuals connected to your organization? Things to consider: + +* Are they in different organizational units, for example, the medical school and the business school, or internal members and visiting students, etc. +* Are they in specific departments? +* What formal and informal groups are they in? For example, project groups, mailing lists, role groups (like department heads), collaborations (like the holiday party committee) + +In the **Memberships** box of the worksheet, jot down several collections of people that each of your `CO Persons` :gear: are a part of. + +Share what you have written with someone else in the workshop. Is there anything that they considered that you might want to include on your sheet as well? + +[15 min] + +--- +< TO BE UPDATED > + +# Terminology + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +:gear: `Org Identity` | the representation of a person in other contexts outside of COmanage +:gear: `Identity Source` | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID. +:gear: `Identity Source Records` | COmanage's cached value of the values at the source + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage + +## Slides + +To be included + +--- + +NEXT SECTION: [4. Permissions](/_episodes/04-permissions.md) + +PREVIOUS SECTION: [2. The Identity Org Object](/_episodes/02-orgIdentity.md) + +LESSON OVERVIEW: [CO310 - Modeling People in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) \ No newline at end of file diff --git a/_episodes/04-authenticators.md b/_episodes/04-authenticators.md deleted file mode 100644 index c52f544..0000000 --- a/_episodes/04-authenticators.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: "About Authenticators" -teaching: 15 -exercises: 10 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -# 4. About Authenticators - -< This episode needs to be edited > - -Authenticators are used to prove a CO Person's identity to an application or service. An Authenticator combined with an Identifier is a credential. Although COmanage is built around the concept of external identity, there are a number of use cases where it makes sense for collaboration managed credentials to be used to access services, including - -* Using SSH Keys ([CO-1493](https://bugs.internet2.edu/jira/browse/CO-1493)) or Passwords to log in to unix based servers. -* Certificate access to grid computing resources. -* Multi factor authentication, using a collaboration issued second factor. - -Authenticators are available as of registry v3.1.0. - -## Terminology - -There are multiple concepts with similar names. For clarity, here are their definitions: - -* **Authenticator Plugin**: A [COmanage Plugin](https://spaces.at.internet2.edu/display/COmanage/Authenticator+Plugins), that implements the interfaces to a specific authentication technology (such as Passwords or SSH Keys). -* **Authenticator Backend**: An [instantiated](https://spaces.at.internet2.edu/display/COmanage/Writing+Registry+Plugins#WritingRegistryPlugins-WritingRegistryPlugins-InstantiatedvsNon-Instantiated) Authenticator Plugin. That is, an Authenticator Plugin with a specific configuration. -* **Authenticator**: A specific instance of an authenticator attached to a CO Person. eg: A given person's password. - -## How Authenticators Work - -Because Authenticators are collaboration issued, they are attached to the CO Person, not to Organizational Identities (as for [external credentials](https://spaces.at.internet2.edu/display/COmanage/Understanding+Registry+People+Types)). In general, Registry does not know how to validate Authenticators, they (or metadata about them) are simply stored in the Registry database. Authenticators are passed to the [provisioning infrastructure](https://spaces.at.internet2.edu/display/COmanage/Provisioning+From+Registry), so that [Provisioning Plugins](https://spaces.at.internet2.edu/display/COmanage/Writing+Registry+Plugins) may use the Authenticator information to populate downstream services. For example, the [LDAP Provisioner Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin) may write a user password or SSH key attribute using Authenticator data. - -### Single vs Multiple Values - -Authenticator Backends can support single or multiple values, as determined by the Authenticator Plugin. In general, whether an Authenticator Plugin supports multiple values depends on whether it makes sense for the CO Person to be able to manage multiple Authenticators of the same type for themselves. - -For example, the [Password Authenticator Plugin](https://spaces.at.internet2.edu/display/COmanage/Password+Authenticator+Plugin) is single valued, meaning each instantiated backend may only have one password associated with it. (A given PasswordAuthenticator hasOne Password per CO Person.) If you want to support multiple passwords to be managed, you can instantiate multiple Backends. A CO Person cannot create a second password for themselves. - -On the other hand, the Certificate Authenticator Plugin is multi-valued, meaning each instantiated backend may support multiple certificates. (A given CertificateAuthenticator hasMany Certificate per CO Person.) This allows a CO Person to upload multiple certificates to attach to their operational record. (In general, there is no need to multiply instantiate an Authenticator Plugin that supports multiple values, although it is technically possible to do so.) - -## Authenticator Operations - -Registry supports the following operations on Authenticators for a CO Person: - -* **Manage**: Set or change the current Authenticator (for example, change a password). This operation may be performed by the CO Person (self service) or an administrator. -* **Lock**: Lock the Authenticator so it may not be changed or used. When locked, the Authenticator is not available to provisioners. This operation may only be performed by an administrator. For Authenticator Backends that support multiple values, locking applies to the entire Authenticator Backend (ie: all Authenticators for the CO Person, including the ability to add new ones). -* **Unlock**: Unlock the Authenticator so it may again be changed or used. If previously set, the original value will be maintained. This operation may only be performed by an administrator. For Authenticator Backends that support multiple values, unlocking applies to the entire Authenticator Backend. -* **Reset**: Clear the current Authenticator. This operation may only be performed by an administrator. Once reset, the CO Person may again manage the authenticator (if it is not locked). This operation is not supported for Authenticator Backends that support multiple values, although individual values maybe edited or deleted. - -Upon any operation, the provisioning infrastructure is executed so that the Provisioners may perform any necessary actions. Authenticators may be manually reprovisioned by the usual [manual reprovisioning process](https://spaces.at.internet2.edu/display/COmanage/Provisioning+From+Registry#ProvisioningFromRegistry-ProvisioningFromRegistry-ManualProvisioning). - -As of Registry v3.3.0, Authenticators may be collected as part of an [Enrollment Flow](https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration#RegistryEnrollmentFlowConfiguration-RegistryEnrollmentFlowConfiguration-EstablishingAuthenticators). - -## Using Authenticators To Log Into Registry - -Because Authenticators are attached to the CO Person, not to Organizational Identities, and because Registry does not know how to validate Authenticators, they cannot be directly used to log into Registry. The following additional steps are necessary: - -1. Set up an authentication service (eg: [Shibboleth](http://shibboleth.net/products/identity-provider.html), [CAS](https://www.apereo.org/projects/cas), or [mod_authnz_ldap](https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html)) that allows for web based authentication using the Authenticators as provisioned to a suitable target (such as LDAP), and configure [Apache to use this authentication service](https://spaces.at.internet2.edu/display/COmanage/Registry+Installation+-+Source#RegistryInstallation-Source-RegistryInstallation-Source-IntegrateWebServerAuthentication) for Registry. -2. For each CO Person, create an Org Identity (or use an existing one) with an attached Identifier flagged for login. - -# Specific Authentication Services - -## Shibboleth - -### Configuring the Shibboleth Embedded Discovery Service Plugin - -> For configuration instructions for COmanage Registry v0.9.4 and earlier, see [Configuring the Shibboleth Embedded Discovery Service Plugin (0.9.x)](https://spaces.at.internet2.edu/pages/viewpage.action?pageId=68485126). - -If you have chosen to use a SAML2 service provider (SP) for authentication to the Registry and you expect users to want to use more than one login server (identity provider or IdP), you will most likely want to use a SAML2 discovery service to help users choose which IdP to use for login. - -COmanage Registry includes a Shibboleth Embedded Discovery Service (EDS) that you may choose to use as the discovery service. Customization is via _Platform > CMP Enrollment Configurations_. The default COmanage EDS assumes the discovery service feed is available at /Shibboleth.sso/DiscoFeed. For more information on the EDS, see the [EDS documentation](https://wiki.shibboleth.net/confluence/display/EDS10/Embedded+Discovery+Service). - -The discovery service URL is - -``` -https:///registry/pages/eds/index -``` - -If you are using a Shibboleth Native Service Provider (SP) you can configure the SP to use the discovery service by configuring the discoveryProtocol and discoveryURL attributes for the element. For example - -``` - -SAML2 - -``` - - ---- - -# Hands on - Starting our person model - -![Interactive system activity](../assets/img/hands-on-keyboard.png) - -< TO BE UPDATED> - -Think about the sources outside of COmanage where you store information about the people you may be registering. Use the individuals that you wrote down on the [ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) worksheet to think of specific examples. - -In the **Org Identities** box, jot down one or more sources where there are representations for each of the people you have listed in the last exercise. All of the people you have listed may be represented in the same sources, or some may differ. Consider sources from systems, and also consider source like spreadsheet which may contain members of a project team. - -[10 min] - ---- -< TO BE UPDATED > - -# Terminology - -## COmanage Objects - -OBJECT | DESCRIPTION ------- | ----------- -:gear: `Org Identity` | the representation of a person in other contexts outside of COmanage -:gear: `Identity Source` | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID. -:gear: `Identity Source Records` | COmanage's cached value of the values at the source - -## Worksheets - -WORKSHEET | DESCRIPTION ---------- | ----------- -[ :memo: Modeling People](/files/handouts/CO310_ExamplePerson.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage - -## Slides - -To be included - ---- - -NEXT SECTION: [5. About Roles](/_episodes/05-roles.md) - -PREVIOUS SECTION: [3. About Attributes](/_episodes/03-attributes.md) - -LESSON OVERVIEW: [CO310 - Modeling People in COmanage](../index.md) - -WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) \ No newline at end of file diff --git a/_episodes/04-permissions.md b/_episodes/04-permissions.md new file mode 100644 index 0000000..f6fb793 --- /dev/null +++ b/_episodes/04-permissions.md @@ -0,0 +1,112 @@ +--- +title: "About Permissions" +teaching: 20 +exercises: 0 +questions: +- "Question here" +objectives: +- "List the objectives" +keypoints: +- "List the key takeaways for the episode" +--- + +# 3. About Permissions + +Several actions within COmanage require specific permissions to perform them. Permissions are usually granted by making a `CO Person` :gear: a part of a group, and then granting permission to that group to do specific tasks. + +The types of actions that can require special permission include: + +* Configuring the COmanage platform or specific organizations or collaborations represented in the platform +* Enrolling (registering) people in COmanage +* Managing `CO Person` :gear: objects, their connected attributes (information), and the values stored for the person. +* Managing one's own attributes (information) (Self Service Permissions) +* Creating and managing groups and who is included in the groups + +# Automatic permission groups + +Some groups for managing these permissions are created automatically when configuring the objects that you will use when modeling your organization. (Next lesson!) + +* **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._ + +## Attributes that may be configured for self service + +* `CO Person` :gear: Name +* `CO Person` :gear: Role Address +* `CO Person` :gear: EmailAddress +* `CO Person Role` :gear: TelephoneNumber +* `CO Person` :gear: Identifier +* `CO Person` :gear: URL (as of v3.1.0) + +_By default, these attributes are read only._ + +## Attributes that are never available for self service + +* `CO Person` :gear: Status +* `CO Person Role` :gear: attributes +* All attributes attached to an `Org Identity` :gear: record + +--- + +# Hands on - Starting our person model + +![Interactive system activity](../assets/img/hands-on-keyboard.png) + +Consider the people that you have been using as examples in your [ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf) worksheet. What permissions would each of these individuals have? + +* Consider the items that you listed in the Memberships section. Would this person be an Owner or Administrator for any of these collections of people? +* Would this person be considered a platform administrator, responsible for setting up organizational structure within COmanage? +* Would this person be allowed to change attributes (information) about themselves, for example, email address, name or phone number? +* Would this person be allowed to self enroll for any memberships? If so, what types of groups would this person elect to be a part of? +* Is this person considered a guest - i.e., the person has a limited connection to your organization or collaboration. + +Jot down your thoughts on the worksheet. There are check boxes to indicate things like administrative or ownership permissions as well as self service or self enrollment privileges. + +[10 min] + +--- +< TO BE UPDATED > + +# Terminology + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`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. + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[ :memo: Modeling People](/files/handouts/CO310-ModelingPeople.pdf) | Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage + +## Slides + +To be included + +--- + +NEXT SECTION: [5. Your first person!](/_episodes/05-firstPerson.md) + +PREVIOUS SECTION: [3. About Authenticators](/_episodes/03-authenticators.md) + +LESSON OVERVIEW: [CO310 - Modeling People in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) \ No newline at end of file diff --git a/_episodes/05-firstPerson.md b/_episodes/05-firstPerson.md new file mode 100644 index 0000000..89e2367 --- /dev/null +++ b/_episodes/05-firstPerson.md @@ -0,0 +1,67 @@ +--- +title: "Your first person" +teaching: 0 +exercises: 15 +questions: +- "Question here" +objectives: +- "List the objectives" +keypoints: +- "List the key takeaways for the episode" +--- + +# Your first person! + +You have installed COmanage; the first person is created during this process. By default, this person holds the role of Platform Administrator. We will use this person to explore some of the concepts that we have learned about, and see how COmanage expresses them. + +We won't be changing this person. You will create a record for yourself in a later lesson. + +# Sign into the Registry + +1. Using the credentials you specified as part of the COmanage setup, sign into the system. These credentials have Platform Administrator privileges. + +# View the `Org Identity` Object :gear: + +1. Click on the upper right corner of the screen to expand the user menu. +2. From the menu, select the Organizational Identity shown. This action will open the Organization Identity in "view" mode. + +![screen shot - select the Org Identity from the user menu](/assets/img/05-OpenOrgIdentity.png) + +3. Explore the attributes and associated items that we talked about: + * Name and affiliation + * Linked Identifiers + * Lists of email addresses + * Linked `CO Person` :gear: +4. Click on the Edit button to get a feel for the experience of changing attributes. This experience is similar to the **Self Service** experience that may be enabled for some users. + * Try adding another name - notice what it looks like when saved, for example, one of these names is designated as the "primary" name. + * Add an email address + +# View the connected `CO Person` :gear: object + +1. Click on the "view" button next to the `CO Person` :gear: object to view the object. (you can do this from the view or edit screens of the `Org Identity` :gear:) + +![screen shot - view the connected CO Person object](/assets/img/05-ViewCOPerson.png) + +2. Explore the attributes and associated items that we talked about. Notice the differences between the things connected to the `Org Identity` :gear: and the `CO Person` :gear: + * Name and affiliation + * Linked Identifiers + * Lists of email addresses + * Status + +3. Notice the groups that this `CO Person` was automatically assigned to. We will talk about groups in the next lesson. + +# Restore things + +Before we move onto the next lesson, restore any changes that you may have made, particularly in adding names or email addresses. This action will help ensure that we all have similar experiences when doing the next set of hands on activities. + +--- + +PREVIOUS SECTION: [3. About Authenticators](/_episodes/03-authenticators.md) + +LESSON OVERVIEW: [CO310 - Modeling People in COmanage](../index.md) + +--- + +NEXT LESSON: [CO320 - Modeling Your Organization in COmanage](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blog/master/index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) \ No newline at end of file diff --git a/_episodes/05-roles.md b/_episodes/05-roles.md deleted file mode 100644 index 1c9feee..0000000 --- a/_episodes/05-roles.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: "About Roles" -teaching: 20 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -## Managing Roles - -See the table on the COmanage wiki for a [comparison chart of tasks](https://spaces.at.internet2.edu/display/COmanage/Roles) that each role can perform. - -## What can people do when they assume a role? - -COmanage uses roles to manage the functionality that different users can use. This functionality falls into the following broad categories: - -* **Collaborative Organization (CO) Management** - Management of the top-level object in COmanage. -* **Person Management** - The ability to add and edit the information about people in COmanage, and control their access to resources. -* **Role/ Group Management** - The ability to assign and adjust administrative roles and group membership -* **Provisioning** - Management of automated and manual provisioning - access to external resources -* **Content** - The ability to access certain types of COmanage content -* **Audit** - The ability to review and report on historical actions taken within COmanage -* **System Administration** - For the technical maintenance of COmanage - - NOTE: this list needs to be reconciled against the table of Registry Permissions](https://spaces.at.internet2.edu/display/COmanage/Registry+Permissions) - -## 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. - -### Making an existing member an administrator - ->> This needs to be vetted and screen shots are needed - -1. From the COmanage Registry home page, click on your CO. -2. From the CO welcome page, click on the drop down menu for 'People' and select 'My Population'. -3. Select the member that you would like to make into a CO admin. -4. On the member's page, click on 'Manage Group Memberships'. -5. Select 'member' on the admin group line. - -## Non-administrator roles - -### CO Participant - - - -### Guest - - - -### Group Owner - - - -### Group Member - - - -### CO Person - - - -### Anonymous - - - -### Sponsor - -Each [CO Person Role](https://spaces.at.internet2.edu/display/COmanage/Understanding+Registry+People+Types) can have a sponsor attached to it. The sponsor can be selected via an Enrollment Flow Attribute, or subsequently by manually editing the record. - -The pool of eligible sponsors can be configured via CO Settings as follows: - -CO Administrators -CO and COU Administrators -Members of a specified CO Group -Any valid CO Person -The sponsors capability may also be disabled. This may be advisable for deployments with large user populations, as disabling sponsors will reduce some database querying. - -If a sponsor subsequently becomes ineligible to be a sponsor, they will remain as sponsors for any existing records. However, they may not become sponsors of new records, and any existing record must specify a new sponsor if edited. - -Sponsor status may also be used in [Expiration Policies](https://spaces.at.internet2.edu/display/COmanage/Expiration+Policies). Note that expiration policies apply to the status of the sponsoring CO Person (ie: whether or not the CO Person is valid) and not to whether or not the CO Person is eligible to be a sponsor ([CO-1140](https://bugs.internet2.edu/jira/browse/CO-1140)). - -## 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) | | - - -# 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. - -# Terminology - -## COmanage Objects - -OBJECT | DESCRIPTION ------- | ----------- -:gear: `CO Person Role` | the representation of a person's role in COmanage. This object describe the person's role with the collections of people within your organization or collaboration. These objects are attached to :gear: `CO Person` objects; there may be any number of Roles. \ No newline at end of file diff --git a/_episodes/08-youTryFirstPerson.md b/_episodes/08-youTryFirstPerson.md deleted file mode 100644 index d4da76d..0000000 --- a/_episodes/08-youTryFirstPerson.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Your first person" -teaching: 15 -exercises: 10 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -# Managing Organizational Identity Source Records - -The terminology used by Registry can be a little confusing when looking at person records related to Organizational Identity Sources. - -* **View Organizational Identity**: Retrieves the current Org Identity operational record used by Registry in normal operations. -* **View Organizational Identity Source**: Performs a live query against the Org Identity Source backend and retrieves the current data as known to the backend. ie: This is the source's current data. -* **View Organizational Identity Source Record**: Retrieves the last data retrieved from the backend and used to create or update an Org Identity. ie: This is Registry's copy of the source data. -* **Add New Org Identity From Source**: Create a new Org Identity based on the Org Identity Source's data. In addition, this will create an Organizational Identity Source Record. -* **Resync Org Identity From Source**: Update the Org Identity and Organizational Identity Source Record using the latest (current) data available from the Org Identity Source. -* **Configuration >> Organizational Identity Sources**: Manage the plugins used to define and query one or more Org Identity Sources. \ No newline at end of file diff --git a/_episodes/CO370_05-old-groupFeatures.md b/_episodes/CO370_05-old-groupFeatures.md deleted file mode 100644 index 71d489b..0000000 --- a/_episodes/CO370_05-old-groupFeatures.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Group features" -teaching: 20 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -# 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) \ No newline at end of file diff --git a/_episodes/03-attributes.md b/_episodes/notUsed-attributes.md similarity index 100% rename from _episodes/03-attributes.md rename to _episodes/notUsed-attributes.md diff --git a/assets/img/05-OpenOrgIdentity.png b/assets/img/05-OpenOrgIdentity.png new file mode 100644 index 0000000..f232bed Binary files /dev/null and b/assets/img/05-OpenOrgIdentity.png differ diff --git a/assets/img/05-ViewCOPerson.png b/assets/img/05-ViewCOPerson.png new file mode 100644 index 0000000..c27e888 Binary files /dev/null and b/assets/img/05-ViewCOPerson.png differ diff --git a/files/handouts/CO310-ModelingPeople.pdf b/files/handouts/CO310-ModelingPeople.pdf new file mode 100644 index 0000000..486da42 Binary files /dev/null and b/files/handouts/CO310-ModelingPeople.pdf differ diff --git a/files/handouts/CO310_ExamplePerson.pdf b/files/handouts/CO310_ExamplePerson.pdf deleted file mode 100644 index 8207d03..0000000 Binary files a/files/handouts/CO310_ExamplePerson.pdf and /dev/null differ diff --git a/index.md b/index.md index 54601b7..f3c3249 100644 --- a/index.md +++ b/index.md @@ -25,19 +25,14 @@ Time | Section | Description   | [Setup](/setup.md) | Prepare for the lesson 00:25 | [1. The CO Person Object](/_episodes/01-COperson.md) | Understand the CO Person object - the primary object for representing people in COmanage. What does this object contain? 00:25 | [2. The Org Identity Object](/_episodes/02-orgIdentity.md) | Understanding Org Identity Objects and how they are connected to representations of people external to COmanage. - -5. [3. About Roles](/_episodes/03-roles.md) -6. [4. About Groups](/_episodes/04-groups.md) -7. [5. Model Your Own People](/_episodes/05-youTryModelPeople.md) -8. [6. Your first person](/_episodes/06-youTryFirstPerson.md) - -Not used - -* [About Attributes](/_episodes/notUsed-attributes.md) - +00:15 | [3. Memberships](/_episodes/03-memberships.md) | Understanding the the types of grouping that people in your organization or collaboration form is helpful when modeling your organization. +??? | [4. Permissions](/_episodes/04-permissions.md) | +??? | [5. Your first person](/_episodes/05-firstPerson.md) | Sign into COmanage and explore what these objects and concepts look like in the system. _The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._ --- +NEXT LESSON: [CO320 - Modeling Your Organization in COmanage](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blog/master/index.md) + WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) \ No newline at end of file