This document describes the Registry Enrollment mechanism introduced as part of COmanage Registry v0.9.4. For Registry Enrollment in older versions, see Registry Enrollment (Rev 1, Registry 0.9.3 and earlier).

About Registry Enrollment

By default, COmanage Registry uses an invitation based workflow.

COmanage Registry can also use customized Enrollment Flows to onboard new people into each organization. Enrollment Flows consists of a series of pre-defined steps, the execution of which is managed by Registry in accordance with the configuration of each specific Flow.

Enrollment Flow Steps

See also: Registry Enrollment Flow Diagram

A step may be considered RequiredOptional, or Not Permitted, in accordance with the configuration. A Required step will execute both the core Registry functionality, as well as any Plugins. An Optional step will only execute Plugins, the core functionality will be skipped. Not Permitted means neither core nor Plugin functionality will be executed.

The order steps execute in may vary according to flow configuration.

Some "internal" steps are not documented here.

StepDescriptionCore Step Executes IfPlugins Run If Core Doesn't? (Optional)Petition Status Following StepSince
startInitial step of an enrollment flow. The Petition artifact is created following successful completion (including any Plugins) of this step.Introduction Text is definedYesCreatedv0.9.4
selectEnrolleeSelect an existing identity (CO Person or Org Identity) for this enrollment.Identity Matching is set to Self or SelectNoCreatedv0.9.4
selectOrgIdentitySelect an Org Identity via an Org Identity Source for this enrollment.One or more Enrollment Sources is attached in Search mode, and the petitioner is an adminNoCreatedv2.0.0
petitionerAttributesCollect attributes from the Petitioner.Any Enrollment Attributes are definedYesCreated*v0.9.4
duplicateCheckCall out to an external Identity Match serverMatch Policy is ExternalYesCreatedv4.1.0
tandcPetitionerRequire agreement to Registry Terms and Conditions.Terms and Conditions Mode is set to Explicit Consent or Implied Consent, and at least one T&C is Active, and Petitioner Enrollment Authorization is None or Authenticated User.Yes (if Mode is Explicit Consent or Implied Consent)Createdv4.1.0
sendConfirmationSend an email to confirm deliverability of Enrollee email address.Require Confirmation of Email is setNo

Pending Confirmation

processConfirmationProcess the response to the email sent in the sendConfirmation step.Require Confirmation of Email is setNoConfirmed or Declinedv0.9.4

The identifier used by the enrollee to authenticate (eg: $REMOTE_USER) is attached to the Org Identity created by the Petition.

Automatic linking for existing identifiers is handled in this step.

Require Confirmation of Email and Require Authentication are setNoConfirmedv0.9.4
checkEligibilityDetermine if the Enrollee is allowed to enroll, by querying an Organizational Identity Source for eligibility.One or more Enrollment Sources is attached is attached in Search or Search, Required mode, and the petitioner is not an adminNoConfirmed or Deniedv2.0.0
tandcAgreementRequire agreement to Registry Terms and Conditions.Terms and Conditions Mode is set to Explicit Consent or Implied Consent, and at least one T&C is Active, and (as of Registry v4.1.0) Petitioner Enrollment Authorization is not None or Authenticated User.Yes (if Mode is Explicit Consent or Implied Consent)Confirmedv4.0.0
establishAuthenticatorsAllow the Enrollee to set up Authenticators.Establish Authenticators is setNoConfirmedv3.3.0
requestVettingRequest Vetting for the Enrollee.Request Vetting is setNoPending Vettingv4.1.0
sendApproverNotificationNotify the approvers configured for the Enrollment Flow that the Petition is read for review and approval.Require Approval For Enrollment is setNoPending Approvalv0.9.4
approveProcess Petition approval.Require Approval For Enrollment is setNoApprovedv0.9.4
denyProcess Petition denial.Require Approval For Enrollment is setNoDeniedv0.9.4
sendApprovalNotificationNotify the enrollee that their Petition has been approved.Require Approval For Enrollment is setNoApprovedv0.9.4
finalizeIf the Petition is not denied, assign identifiers and set person status to Active.
NoFinalized or Deniedv0.9.4
provisionIf the Petition is finalized, provision services.

* New Person/Role status set to Pending

Plugin Execution

Enrollment Flows support Plugins as a way of customizing beyond what is supported out of the box. See Writing Registry Plugins for more details.

Plugins are executed after the core step has completed, or if the step is considered Optional. When a Plugin is executed, handoff is via a URL. More details about this are in the Plugin Documentation. Because Plugins must be run one at a time, a specific ordering is defined in order to ensure predictability. For Registry v3.3.x and earlier, Plugins are executed alphabetically. For Registry v4.0.0 and later, Plugins are executed in the order defined in the Enrollment Flow Wedge configuration for the relevant Enrollment Flow. Once all Plugins have been run, the next step will be initiated.

Plugins are only executed for the steps documented here. "Internal" steps are not accessible to Plugins.

Firefox Limitation

Firefox has a "feature" that limits the number of redirects that may be issued, to 20 by default. This is to work around potential looping situations, but unlike other browsers that perform actual loop detection, Firefox simply maintains a counter and stops when the limit is reached. Since enrollment flows are redirect based, this cause a problem when large numbers of steps execute without user intervention. The problem is made linearly worse when Enroller plugins are configured.

As a workaround (CO-1224), Registry will introduce a "splash page" with a meta refresh tag at the beginning of each step in order to reset the count. While this solves the problem in most instances, if you install a sufficient number of Enroller plugins (around 20 or so), you may see issues with Firefox interrupting the flow.

  • No labels