From 886f61839314d3adf4e0c5265d7d329a37a8b611 Mon Sep 17 00:00:00 2001 From: selyesa Date: Mon, 27 Jul 2026 11:09:04 +0200 Subject: [PATCH 1/2] Create PRIVACY.md for Registration --- components/ILIAS/Registration/PRIVACY.md | 114 +++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 components/ILIAS/Registration/PRIVACY.md diff --git a/components/ILIAS/Registration/PRIVACY.md b/components/ILIAS/Registration/PRIVACY.md new file mode 100644 index 000000000000..3b6494b14191 --- /dev/null +++ b/components/ILIAS/Registration/PRIVACY.md @@ -0,0 +1,114 @@ +# Registration Privacy + +> **Disclaimer: This documentation does not guarantee completeness or accuracy. Please report any missing or incorrect information by submitting a [Pull Request](docs/development/contributing.md#pull-request-to-the-repositories) or, if you prefer, via the [ILIAS bug tracker](https://mantis.ilias.de). When using the bug tracker, please select the corresponding component in the **Category** field.** + +## General Information + +The Registration component handles the self-registration process that allows new users to create +their own accounts in an ILIAS installation. It supports multiple registration modes that affect +how personal data is processed: disabled registration, direct registration, registration with +administrative approval, registration with email confirmation (dual opt-in), and registration +exclusively via registration codes. + +The component does **not** store user profile data itself. During registration, the user-entered +profile data (name, email, etc.) is delegated to the User component for storage. However, the +Registration component does manage its own data in two areas: **registration codes** (an +administrative tool for controlling access) and **pending dual opt-in registrations** (temporary +data for the email confirmation workflow). + +Registration settings such as registration type, allowed email domains, approval recipients, and +hash lifetime are stored in the global ILIAS settings (`ilSetting`) and do not contain personal +data beyond the user IDs of configured approval recipients. + +## Integrated Components + +- The Registration component employs the following components, please consult the respective + PRIVACY.md files: + - [AccessControl](https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/components/ILIAS/AccessControl/PRIVACY.md) — manages permissions for the registration + settings administration and registration code management. + - [Mail](https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/components/ILIAS/Mail/PRIVACY.md) — the Registration component sends notification emails to + approval recipients and confirmation/welcome emails to newly registered users. + - User — the Registration component creates new user accounts via the User component. All + user profile data (name, email, login, password, language preference) is stored by the + User component. User preferences (contact settings, chat settings) are also written via + the User component. + - LegalDocuments — the Registration component integrates with the Legal Documents service + to present and record agreement to terms of service during self-registration. + +## Data being stored + +- **Registration code**: When a person with the "Write" permission generates registration codes, + each **code string** is stored in the `reg_registration_codes` table together with a + **generation timestamp**, an assigned **global role ID**, optional **local role IDs**, an + **access limitation mode** and its parameters, and flags indicating whether the code is valid + for registration and/or account extension. These codes do not contain personal data themselves, + but they are linked to roles and access policies. +- **Registration code usage timestamp**: When a user redeems a registration code during + self-registration, the **timestamp** of usage is written to the `used` column of the + `reg_registration_codes` table. The code itself does not record **which** user redeemed it. +- **Pending registration user ID**: When dual opt-in (email confirmation) registration is active, + the **user ID** of the newly created (but not yet activated) user account is stored in the + `reg_dual_opt_in` table to track the pending confirmation. +- **Confirmation hash**: A unique **hash value** is generated and stored in the + `reg_dual_opt_in` table alongside the user ID. This hash is sent to the user's email address + as part of the confirmation link. +- **Pending registration creation timestamp**: The **creation date** (as Unix timestamp) of + the pending registration is stored in the `reg_dual_opt_in` table to determine whether the + confirmation link has expired. +- **Email-to-role assignments**: The `reg_er_assignments` table stores mappings between + **email domain patterns** and **role IDs** for automatic role assignment during registration. + These are administrative configuration data and do not contain personal user data. +- **Role access limitations**: The `reg_access_limit` table stores **access limitation modes** + (absolute date, relative duration, or unlimited) per role. These are administrative + configuration data and do not contain personal user data. +- **Approval recipient user IDs**: The **user IDs** of persons designated to receive + notification emails when new users register are stored in the global ILIAS settings + (key `approve_recipient`). + +## Data being presented + +- **Each user** is presented with their own registration form data during the self-registration + process. After successful registration, a confirmation message displays the user's **full + name**. +- **Persons with the "Read" permission** on the Registration Administration can view: + - all registration settings, including configured approval recipient login names. + - the registration codes table showing **code strings**, **generation timestamps**, + **usage timestamps**, assigned **roles**, and **access limitations**. +- **Persons with the "Write" permission** on the Registration Administration can additionally: + - generate new registration codes. + - delete registration codes. + - export registration codes as a text file. + - modify registration settings, role assignments, email domain mappings, and access + limitations. +- **Approval recipients** (persons configured in the registration settings) receive email + notifications containing the new user's **profile data** (as provided by the User component's + `getProfileAsString` method) when a new user registers. + +## Data being deleted + +- **When a registration code is deleted** by a person with the "Write" permission on the + Registration Administration: the code record is deleted from the `reg_registration_codes` + table, including the code string, generation timestamp, usage timestamp, and all associated + role and access limitation data. +- **When a dual opt-in confirmation succeeds**: the pending registration record is deleted from + the `reg_dual_opt_in` table after the user account is activated. The hash value and creation + timestamp are removed. +- **When a dual opt-in confirmation link expires**: expired pending registrations are identified + by comparing the creation timestamp against the configured hash lifetime. The + `DualOptInServiceImpl::deleteExpiredUserObjects` method deletes both the pending registration + record from `reg_dual_opt_in` and the associated (still inactive) user account. +- **When a user account is deleted**: the Registration component listens for the + `Services/User::deleteUser` event and deletes any associated pending registration records + from the `reg_dual_opt_in` table via `PendingRegistrationDatabaseRepository::deleteByUserId`. +- **Registration codes are not automatically deleted** when a user account is deleted. Since + the `reg_registration_codes` table does not store which user redeemed a code, there is no + personal data linkage to clean up. + +## Data being exported + +- **Persons with the "Write" permission** on the Registration Administration can export + registration codes as a plain-text file. The exported data contains only the **code strings** + and does not include personal user data. +- There is no export functionality for pending dual opt-in registration data. +- User profile data entered during registration is stored and can be exported via the User + component; the Registration component itself does not provide a separate user data export. From 618df4e38fc98539bd44372eb1ce31a3c43d2e14 Mon Sep 17 00:00:00 2001 From: selyesa Date: Tue, 4 Aug 2026 15:17:47 +0200 Subject: [PATCH 2/2] Update PRIVACY.md Registration Address review comments --- components/ILIAS/Registration/PRIVACY.md | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/components/ILIAS/Registration/PRIVACY.md b/components/ILIAS/Registration/PRIVACY.md index 3b6494b14191..69eea301483f 100644 --- a/components/ILIAS/Registration/PRIVACY.md +++ b/components/ILIAS/Registration/PRIVACY.md @@ -1,6 +1,6 @@ # Registration Privacy -> **Disclaimer: This documentation does not guarantee completeness or accuracy. Please report any missing or incorrect information by submitting a [Pull Request](docs/development/contributing.md#pull-request-to-the-repositories) or, if you prefer, via the [ILIAS bug tracker](https://mantis.ilias.de). When using the bug tracker, please select the corresponding component in the **Category** field.** +> **Disclaimer: This documentation does not guarantee completeness or accuracy. Please report any missing or incorrect information by submitting a [Pull Request](https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/docs/development/contributing.md#pull-request-to-the-repositories) or, if you prefer, via the [ILIAS bug tracker](https://mantis.ilias.de). When using the bug tracker, please select the corresponding component in the **Category** field.** ## General Information @@ -37,12 +37,6 @@ data beyond the user IDs of configured approval recipients. ## Data being stored -- **Registration code**: When a person with the "Write" permission generates registration codes, - each **code string** is stored in the `reg_registration_codes` table together with a - **generation timestamp**, an assigned **global role ID**, optional **local role IDs**, an - **access limitation mode** and its parameters, and flags indicating whether the code is valid - for registration and/or account extension. These codes do not contain personal data themselves, - but they are linked to roles and access policies. - **Registration code usage timestamp**: When a user redeems a registration code during self-registration, the **timestamp** of usage is written to the `used` column of the `reg_registration_codes` table. The code itself does not record **which** user redeemed it. @@ -55,12 +49,6 @@ data beyond the user IDs of configured approval recipients. - **Pending registration creation timestamp**: The **creation date** (as Unix timestamp) of the pending registration is stored in the `reg_dual_opt_in` table to determine whether the confirmation link has expired. -- **Email-to-role assignments**: The `reg_er_assignments` table stores mappings between - **email domain patterns** and **role IDs** for automatic role assignment during registration. - These are administrative configuration data and do not contain personal user data. -- **Role access limitations**: The `reg_access_limit` table stores **access limitation modes** - (absolute date, relative duration, or unlimited) per role. These are administrative - configuration data and do not contain personal user data. - **Approval recipient user IDs**: The **user IDs** of persons designated to receive notification emails when new users register are stored in the global ILIAS settings (key `approve_recipient`).