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⚙️, not to Org 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.

Accessing services with authenticators

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 or Passwords to log in to UNIX based servers.
• Certificate access to grid computing resources.
• Multi factor authentication, using a collaboration issued second factor.

Terminology

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.

For example, the 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⚙️.) 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. (Each one can have many Certificates per CO Person⚙️.) This allows a CO Person to upload multiple certificates to attach to their record in COmanage.

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.

DEMONSTRATION - setting up an SSH Authenticator

---