Registration: Double-Opt-in with Account Approval

1 Initial Problem

Currently ILIAS supports two self-registration types where the account is not active after the initial account creation:

• Registration with Approval
  • Users have to be approved by an administrator.
• Registration with E-Mail Confirmation
  • Users have to confirm the provided email address by clicking the link in the email sent after the initial account creation.

Depending on the security regulations of an institition the 'either/or' approach is not sufficient. A self-registration process often requires both traits.

2 Conceptual Summary

Therefore we suggest to introduce a new self-registration type: Double-Opt-in with Account Approval

The new registration type should combine both, requiring an e-mail confirmation of the self-registered users followed by an approval of an administrative account.

At the time being the registration types mentioned above depend on the active flag of the user (databsae table: usr_data, field: active). If both traits should be combined we cannot rely on the active flag anymore. The current implementation if very implicit, which can also lead to problems if an account has been activated by an administrator before the user confirmed the e-mail address. Users will already be able to user ILIAS without the confirmation.

Instead, the necessary information for each process step should be stored separately and explicitly:

• Doulb-Opt-in
  • When did the self-registered user (that's the who, implicitly) confirm the e-mail address?
• Approval
  • Who approved the user account?
  • When (already stored in the ILIAS database)?

If all process steps have been completed, the user account has to be set to active.

2.1 Alternative Approach: Activate Features, don't choose a Registration Type

Instead of introducing a new registration type, thinking of "Features" could be an alternative approach.

• No Registration Possible
• Direct Registration
  • [ ] Enable Account Approval
    • If checked any new user registration has to be approved by an administrator.
  • [ ] Double-Op-In
    • This feature requires an e-mail confirmation by the registered user to activate the account. This avoids self-registration to ILIAS with wrong or non-existent e-mail addresses.
      • Lifetime [ 6000 ]
        • Enter the lifetime (seconds) of confirmation links. Recommended value is 1800 seconds.
  • [ ] Allow Codes
    • This type allows self-registration of users but requires a valid code.

3 User Interface Modifications

3.1 Administration / Users and Roles / Authentication and Registration / ILIAS Auth / Self-Registratiom

3.2 List of Affected Views

• Administration / Users and Roles / Authentication and Registration / ILIAS Auth / Self-Registratiom
• Administration / Users and Roles / User Management / User Profile

3.2.1 User Interface Details

3.3 Administration / Users and Roles / User Management / User Profile

None

3.4 New User Interface Concepts

None

4 Accessibility Implications

None

5 Technical Information

See details above.

6 Privacy

Addtional user related data will be stored with the implementtion of this change request:

• The user id of the approver has be stored in the ILIAS database
• The datetime when the self-registered user confirmed the e-mail address

The data should be exported whereever the "Approval" datetime is exported with ILIAS 8.

If the user account is removed from system, this information must be deleted as well.

7 Security

None

8 Contact

• Author of the Request: Koch, Karola [kkoch],  Solzbacher, Bettina [BettinaSolzbacher], Jansen, Michael [mjansen]
• Maintainer: Registration: 1st Coordinator: Seeland, Per Pascal [PerPascalSeeland], 2nd Coordinator: Jansen, Michael [mjansen] / User: Kergomard, Stephan [skergomard]
• Implementation of the feature is done by: Registration: tba / User: Kergomard, Stephan [skergomard]

9 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

10 Discussion

11 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.