There are multiple concepts with similar names. For clarity, here are their definitions:
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 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. (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.)
Registry supports the following operations on Authenticators for a CO Person:
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.
As of Registry v3.3.0, Authenticators may be collected as part of an Enrollment Flow.
As of Registry v4.0.0, notifications may be sent when an Authenticator is updated. To enable this capability, first define a Message Template with a context of Authenticator. Then, edit the desired Authenticator configuration. Set the Change Message Template to the newly created template.
Custom Authenticator plugins may need to manually trigger this notification. If writing a custom plugin, see the Authenticator Plugins documentation for more information.
As of Registry v4.0.0, URLs of the form /registry/password_authenticator/passwords/manage/authenticatorid:X (ie: that do not specifically include a CO Person ID) will automatically redirect to the current CO Person's Authenticator management page (or require login if there is no current session). This is useful to offer a generic "Manage My Credential" link from a user portal or documentation source.
The type and nature of authenticators used with the Registry can be extended through Plugins.
There are several plugins that are already available for your use:
You can build your own authenticator plugin to extend Registry functionality. Please see the following documentation to get started:
The following database tables are associated with authenticators:
Authenticators are designed as a class of plugins. All plugins have basic settings that are are related to the plugin’s Class. In addition, some plugins have plugin-specific settings to configure the specifics related to the plugin. To configure an Authenticator plugin in Registry you must:
This action will open a form to provide the Authenticator Plugin basic settings as listed below.
Field | Description |
---|---|
Description | The name that users will see when interacting with the authenticator. It should be descriptive of the authenticator. |
Plugin | The plugin that will be used for this Authenticator. |
Status | The Authenticator configuration can either be [ Active ] or [ Suspended ] |
Change Message Template | (optional) When an authenticator is updated the associated CO Person will be sent a message using the specified message template. |
When you have completed the form, click the btn:[ADD] button to display a form to provide plugin-specific configurations (if any).
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:
The Style macro allows the use of CSS to style content. CSS describes how HTML elements should be displayed. https://www.adaptavist.com/doco/display/CFP/Style+Sheet
.home-banner { background: #ffffff; color: #d44415; font-size: 20px; padding: 20px; } .home-banner h1 { color: #5e2b97; font-size:2.5em; } .title-box { border: 0px solid #ff5b2d padding: 10px; padding-bottom: 30px; line-height: 2; font-size: 1.5em; } .title-box > h2 { /*background: #5e2b97;*/ border-top: 3px solid #c2d6d6; bottom: 10px; /*color: #c2d6d6;*/ /*margin-left: -10px;*/ /*margin-right: -10px;*/ padding: 1em 0 0; position: relative; } .cfm-blog-image > img { display: block; margin-left: auto; margin-right: auto; } .about-box { border-top: 1px solid #c2d6d6; border-bottom: 2px solid #c2d6d6; padding: 10px; padding-top: 30px; padding-bottom: 30px; } .about-box > p { font-size: 0.9em; font-style: italic; } .about-box > h3 { font-size: 0.9em; } } |