An enrollment flow allows a user (also know known as a COPerson) to enroll into a CO or COU they were not a member of yet. Enrollment flows are not meant to administer group membership; group administrators (group owners) can do that directly through the Group interface of COmanage. Group membership does not infer any special rights to members, whereas CO and COU membership allows access to specific services.
- creating the petition, entering the relevant values of the enrollee (think of name, email address, organisationorganization)
- confirming the email address, which sends an email to the enrollee
- viewing and accepting (confirming) the enrollment by the enrollee
- approving the enrollment by an administrator
Some of these steps may or may not be optionalare optional depending on the configuration of the enrollment flow.
Enrollment flows reside under the 'Configuration' form of a CO. Only CO administrators can configure these options, other users do not have this link.
The other fields are either less relevant or very obvious and allow administrators to further personalize the enrollment experience.
Enrollment attributes determine the attributes gathered of, from or by the enrollee during the enrollment flow:
This list determines which attributes are gathered and to which destination object the attributes are copied (note: not from which source). Administrators can determine which values are required, which fields are visible and which attributes can be further modified by the user:
- if If using the SamlSource OIS plugin (see below), the authorative IdP attributes are stored non-modifiable in an attached Organisational Identity (OrgIdentity). It is therefore not essential that specific information needs to be non-modifiable to allow administrators to properly identify enrolled COPersons: administrators can always look at the related OrgIdentity with the relevant IdP attributes. This information is clearly visible when perusing an enrolled COPerson's data.
- The SamlSource plugin tries to split a displayName field into givenName and familyName, but it uses a simple algorithm. Consider allowing users to modify their name to avoid cases where this automatic splitting fails, or where users have a different preferred name than their officially registered institute name. This opens the door for people that want to impersonate as someone else, but as mentioned above: administrators have easy access to the IdP provided attributes to correct such cases.
- The email address provided by the IdP might not be the preferred address for this specific CO of that COPerson, so consider allowing users to modify their email address. Alternatively, consider adding a hidden field for the official email address and a modifiable field for the preferred email address
- Please note that copying the IdP provided attributes without allowing users to modify (or even see) the values might violate the user consent and/or the institute privacy guidelines, depending on the scope of the CO and additional policies. In general, it is best practice to only filled required attributes using the IdP provided data as default, but allow users to modify their actual value before proceeding with enrollment.
- For invitation flow enrollment, the IdP attributes are not available yet when these attributes are gathered, so there is no way to copy IdP provided attributes.
A typical attribute configuration form looks like this:
Important fields on this form:
- The attribute you select is the attribute to which the gathered data is copied after completing the enrollment-step. For self-signup enrollments, the Organizational Identity attached to the enrollment is a non-modifiable IdP attribute related identity, so you should not select any attributes related to the Organizational Identity (as it cannot be overwritten). Doing so results in non-descriptive user-errors during enrollment.
- Some attributes are related directly to the COPerson (the identity of the user within the bounds of the CO). If a relevant attribute of the Organizational Identity is selected as attribute (in case of invite-flows), this form displays a 'Copy this attribute to the COPerson record' option, allowing you to match Organizational Identity and COPerson identity. This is specifically useful for attributes like name and email address. Note that this option is not available for all attributes, specifically the COPersonRole attributes (that determine the role this person is playing within the bounds of the CO or COU)
- The fields 'Ignore Authoritative Values' and 'Environment Variable for Default Value' can be left off and empty.
- The 'Take default from OrgIdentitySource' option determines if a 'relevant' attribute value is searched for in any attached OrgIdentity for the current enrollment. This matches for example 'preferred email' to 'preferred email', but if no 'preferred email' exists, it will take any email as default. Because of such cases, it is suggested to always allow users to review-and-modify the gathered attributes.
- The minimal required fields for names are either 'givenName' or 'givenName and familyName' and no other options can be configured.
- If you want users to enroll into a COU or sub-COU, you must add an attribute of type COU (COPersonRole)', which allows you to specify the relevant COU. This attribute can be set hidden, non-modifiable, etc. as required. You can add a Group Membership attribute as well, through which you can enroll users directly into the relevant COU admin group to make them administrator. But in general, managing group membership is done elsewhere, in the COmanage group interface. Promoting a COPerson to COU-administrator requires adding them to the relevant COU admin group and can be done outside any enrollment flow.
An OrgIdentity Source (OIS) is a data store that can supply relevant OrgIdentity attributes based on some common identifier. COmanage typically uses email address as common identifier, which makes storing the right email address more of an issue.