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) 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.
How Authenticators Work
Because Authenticators are collaboration issued, they are attached to the CO Person, not to Organizational Identities (as for external credentials). 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, 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.
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.
- 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.
- 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).
Upon any operation, the provisioning infrastructure is executed so that the Provisioners may perform any necessary actions.
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:
- Set up an authentication service (eg: Shibboleth, CAS, or mod_authnz_ldap) 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 for Registry.
- For each CO Person, create an Org Identity (or use an existing one) with an attached Identifier flagged for login.