Skip to content
Permalink
Browse files

Update the rest of the lesson.

Several open questions, particularly about Plugins and Authenticators and how much should be included in this Workshop.
  • Loading branch information...
lpaglione
lpaglione committed Nov 12, 2019
1 parent b724544 commit 4f9bd1c79e10af4485909aeeb780a3dd89627cdf
Showing with 133 additions and 30 deletions.
  1. +4 −4 _episodes/02-coServices.md
  2. +107 −0 _episodes/03-plugins.md
  3. +19 −25 _episodes/{03-authenticators.md → 04-authenticators.md}
  4. +3 −1 index.md
@@ -14,8 +14,8 @@ lessonOverviewName: "CO330 - Linking to Systems Outside of COmanage"
lessonOverviewURL: "../index.md"
previousEpisodeName: "1. Identifiers"
previousEpisodeURL: "/_episodes/01-identifiers.md"
nextEpisodeName: "3. Authenticators"
nextEpisodeURL: "/_episode/03-authenticators"
nextEpisodeName: "3. About Plugins"
nextEpisodeURL: "/_episode/03-plugins"
---

# 2. Understanding CO Services
@@ -124,9 +124,9 @@ WORKSHEET | DESCRIPTION | Introduced in

---

NEXT SECTION: [3. Authenticators](/_episodes/03-authenticators)
NEXT SECTION: [3. About Plugins](/_episodes/03-plugins.md)

PREVIOUS SECTION: [1. Identifiers](/_episodes/01-identifiers)
PREVIOUS SECTION: [1. Identifiers](/_episodes/01-identifiers.md)

---

@@ -0,0 +1,107 @@
---
title: "About Plugins"
teaching: 20
exercises: 0
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
workshopOverviewName: "COmanage Workshop: Managing Identities & Collaborations"
workshopOverviewURL: "https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md"
lessonOverviewName: "CO330 - Linking to Systems Outside of COmanage"
lessonOverviewURL: "../index.md"
previousEpisodeName: "CO Services"
previousEpisodeURL: "/_episodes/02-coServices.md"
nextEpisodeName: "About Authenticators"
nextEpisodeURL: "/_episodes/04-authenticators.md"
---

# 3. About Plugins

COmanage Registry supports several types of `Plugins`:gear: in order to easily customize and extend Registry functionality. There are a few different ways to make Plugins available for use within Registry, according to how the Plugin is distributed.

* **Core Plugins** - Many Plugins are already set up, and provided as "Core Plugins"; these Plugins ship with COmanage, and are enabled by default.
* **Supported Non-core Plugins** - In addition, there are some Plugins that are less widely used, and while they are shipped with COmanage, they are not enabled by default.
* **External Plugins** - Finally, Plugins can come from other sources (including those you write yourself) to support your needs.

## Types of Plugins

There are several different types of Plugins. A few that we will talk about during this workshop include:

* **Authenticator Plugin** - A COmanage Plugin, that implements the interfaces to a specific authentication technology (such as Passwords or SSH Keys).
* **Enroller Plugin**
* **Provisioner Plugin**

## Where to find Plugins

A set of Plugins can be found in the [COmanage Technical Manual](https://spaces.at.internet2.edu/display/COmanage/COmanage+Registry+Technical+Manual)

## Installing and Enabling Plugins

Core Plugins are already installed and enabled, so no additional action is required to start using them.

Supported Non-core Plugins are included in your COmanage installation, and can be found in the `app/AvailablePlugin` directory. To enable them, they must be accessible from the COmanage Registry `local/Plugin` directory

<<< Suggest a hands on exercise here of checking which plugins are included performing any installations that may be necessary. Full details about installing and using Plugins will not be covered in this workshop, though will be added to the "other topics" section >>>

## Configuring and Using Plugins

Once a Plugin is installed and enabled for use, how it is actually used and/or configured varies according to the Plugin type. We will discuss the details of each Plugin type as we begin to use them.

---

# Terminology & resources

## COmanage Objects :gear:

OBJECT | DESCRIPTION | Introduced in
------ | ----------- | -------------
`Identifier`:gear: | Objects that enable one to connect the information stored about people within the COmanage platform to representations of the same people in systems outside of COmanage | [CO330-01](/_episodes/01-identifiers)
`CO Service`:gear: | Services or applications that can be configured for `CO Persons`:gear: to have access to by participating in the organization or collaboration. | [CO330-02](/_episodes/02-coServices.md)
. | ****** CO320 - Modeling Your Organization in COmanage ****** | .
`CO`:gear: | any formal or informal group of individuals that work collaboratively in a digital setting. They have a goal of a shared infrastructure that supports their collaborations so that the traditional limitations of localized applications may be overcome. | [CO320-01](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/01-co.md)
`COU`:gear: | an organizational structure within a CO that differs in how individuals join and/or leave the group, how applications get provisioned or deprovisioned, who manages person membership and privileges in the group, or in the information stored or used about members of the group. | [CO320-02](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/02-cous.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)
`CO Department`:gear: | A COmanage object that is used to model organizational departments. They can be used to store a number of attributes about the department, including telephone numbers, email addresses, URLs, identifiers, and the sets of people associated with specific responsibilities within the department. | [CO320-04](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/04-departments.md)
. | ****** CO310 - Modeling People in COmanage ****** | .
`CO Person`:gear: | The representation of a person in COmanage | [CO310-01](https://github.internet2.edu/lpaglione/COmg-CO310-modelPeople/blob/master/_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)
`Organizational Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID | [CO310-02](https://github.internet2.edu/lpaglione/COmg-CO310-modelPeople/blob/master/_episodes/02-orgIdentity.md)
`Organizational Identity Source Records`:gear: | COmanage's cached value of the values at the source | [CO310-02](https://github.internet2.edu/lpaglione/COmg-CO310-modelPeople/blob/master/_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](https://github.internet2.edu/lpaglione/COmg-CO310-modelPeople/blob/master/_episodes/04-permissions.md)

## CO Person Roles :crown:

ROLE | DESCRIPTION | Introduced in
---- | ----------- | -------------
. | ****** CO320 - Modeling Your Organization in COmanage ****** | .
`CMP Administrators`:crown: | CMP Administrators are effectively super users, with the ability to perform almost all operations on the platform. | [CO320-01](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/01-co.md)
`CO Administrators`:crown: | `CO`:gear: Administrators are super users _within a CO_. These individuals belong to the CO:admins group of the `CO`:gear:. | [CO320-01](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/01-co.md)
`System Administrators`:crown: | System Administrators have privileges that enable them to maintain the COmanage application. | [CO320-01](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/01-co.md)
`COU Administrators`:crown: | Individuals that have the ability to perform lifecycle management operations on the `CO People`:gear: who have `CO Person Roles`:gear: associated with the `COU`:gear:. | [CO320-02](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/02-cous.md)

## Worksheets

WORKSHEET | DESCRIPTION | Introduced in
--------- | ----------- | -------------
. | ****** CO320 - Modeling Your Organization in COmanage ****** | .
[Modeling Organization :memo:](/files/handouts/CO320-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together | [CO320](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/index.md)
[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance | [CO320-01](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/01-co.md)
[COU Planning Worksheet :memo:](/files/handouts/CO320-02_COUPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. | [CO320-02](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/02-cous.md)
[CO Group Planning Worksheet :memo:](/files/handouts/CO320-03_COGroupPlanningWorksheet.pdf) | Planning worksheet for creating your CO Group(s). Contains all of the configuration sections at a glance. | [CO320-03](https://github.internet2.edu/lpaglione/COmg-CO320-modelOrg/blob/master/_episodes/03-groups.md)
. | ****** CO310 - Modeling People in 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 | [CO310](https://github.internet2.edu/lpaglione/COmg-CO310-modelPeople/blob/master/index.md)

---

PREVIOUS SECTION: [2. `CO Services`:gear: ](/_episodes/02-coServices.md)

---

LESSON OVERVIEW: [CO330 - Linking to Systems Outside of COmanage](../index.md)

NEXT LESSON: [CO340 - Workflows: Enrollment](https://github.internet2.edu/lpaglione/COmg-CO340-workflowEnrollment/blob/master/index.md)

WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md)
@@ -18,30 +18,13 @@ nextEpisodeName:
nextEpisodeURL:
---

# 3. About Plugins

COmanage Registry supports several types of `Plugins`:gear: in order to easily customize and extend Registry functionality. There are a few different ways to make Plugins available for use within Registry, according to how the Plugin is distributed. Once a Plugin is installed and enabled for use, how it is actually used and/or configured varies according to the Plugin type.

* **Core Plugins** - Many Plugins are already set up, and provided as "Core Plugins"; these Plugins ship with COmanage, and are enabled by default.
* **Supported Non-core Plugins** - In addition, there are some Plugins that are less widely used, and while they are shipped with COmanage, they are not enabled by default.
* **External Plugins** - Finally, Plugins can come from other sources (including those you write yourself) to support your needs.

## Types of Plugins

There are several different types of Plugins. A few that we will talk about during this workshop include:

* **Authenticator Plugin** - A COmanage Plugin, that implements the interfaces to a specific authentication technology (such as Passwords or SSH Keys).
* **Enroller Plugin**
* **Provisioner Plugin**


# 4. About Plugins and Authenticators
# 4. About Authenticators

Authenticators are used to prove a CO Person's identity to an application or service. An Authenticator combined with an Identifier is a credential.

## How Authenticators Work

Because Authenticators are collaboration-issued, they are attached to the `CO Person`:gear:, not to Organizational Identities. In general, COmanage does not know how to validate Authenticators, they (or metadata about them) are simply stored in COmanage database. Authenticators are passed to the provisioning infrastructure, so that Provisioning Plugins may use the Authenticator information to populate downstream services. For example, the LDAP Provisioner Plugin may write a user password or SSH key attribute using Authenticator data. We will be talking in depth about provisioning tomorrow.
Because Authenticators are collaboration-issued, they are attached to the `CO Person`:gear:, not to `Org Identities`:gear:. In general, COmanage does not know how to validate Authenticators, they (or metadata about them) are simply stored in COmanage database. Authenticators are passed to the provisioning infrastructure, so that Provisioning Plugins may use the Authenticator information to populate downstream services. For example, the LDAP Provisioner Plugin may write a user password or SSH key attribute using Authenticator data. We will be talking in depth about provisioning tomorrow.

## Accessing services with authenticators

@@ -53,21 +36,21 @@ Although COmanage is built around the concept of external identity, there are a

## Terminology

There are multiple concepts with similar names. For clarity, here are their definitions:
There are multiple concepts with similar names. Here are their definitions:

* **Authenticator Plugin**: A COmanage Plugin, that implements the interfaces to a specific authentication technology (such as Passwords or SSH Keys).
* **Authenticator Backend**: An 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.

### 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.
**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.
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. (Each one has one password `CO Person`:gear:.) 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.)
On the other hand, the Certificate Authenticator Plugin is multi-valued, meaning each instantiated backend may support multiple certificates. (Each one can have many Certificates per `CO Person`:gear:.) This allows a CO Person to upload multiple certificates to attach to their record in COmanage.

## Authenticator Operations
## Authenticator Operations <LADP - maybe too much?)

Registry supports the following operations on Authenticators for a CO Person:

@@ -76,7 +59,18 @@ Registry supports the following operations on Authenticators for a CO Person:
* **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).
# Hands On - setting up an SSH Authenticator

## Install the authenticator

## Configure the authenticator

1. Sign in (CO Admin and CMP Admin?)
2. Go to CO & CO Configuration
3. Go to the **Authenticators** link
4. Select **Add Authenticator**
5. Configure the SSH plugin that you just installed
6. Use it?

---

@@ -23,7 +23,8 @@ Time | Section | Description
&nbsp; | [Setup](/setup/) | Prepare for the lesson
00:35 | [1. Identifiers](/_episodes/01-identifiers.md) | Learn the importance of identifiers within COmanage and their use when connecting to other systems as sources or for provisioning. Understand identifier formats and how to make identifier assignments to `CO Persons`:gear:
00:20 | [2. CO Services](/_episodes/02-coServices.md) | Configure a group of services that can be accessed by those in your `CO`:gear:
00:30 | [3. Authenticators](/_episodes/03-authenticators.md) | Learn how authenticators work to enable authenticated access to services. Understand what kinds are supported, and how alternate forms, like SSH keys, are supported.
00:10 | [3. About Plugins](/_episodes/03-plugins.md) | Learn about how Plugins are used to extend the capabilities of COmanage and about the three types that we will discuss during the workshop.
00:30 | [4. Authenticators](/_episodes/04-authenticators.md) | Learn how authenticators work to enable authenticated access to services. Understand what kinds are supported, and how alternate forms, like SSH keys, are supported.

_The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._

@@ -37,6 +38,7 @@ OBJECT | DESCRIPTION | Introduced in
------ | ----------- | -------------
`Identifier`:gear: | Objects that enable one to connect the information stored about people within the COmanage platform to representations of the same people in systems outside of COmanage | [CO330-01](/_episodes/01-identifiers)
`CO Service`:gear: | Services or applications that can be configured for `CO Persons`:gear: to have access to by participating in the organization or collaboration. | [CO330-02](/_episodes/02-coServices.md)
`Plugin`:gear: | Components that are used to easily customize and extend COmanage Registry functionality. | [CO330-03](/_episodes/03-plugins.md)

---

0 comments on commit 4f9bd1c

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