Table of Contents

Protection of Personal Data (GDPR)

The Ometa Framework, as an integration platform, acts as middleware, connecting disparate data sources into a unified solution. This process necessitates the transfer of various data types through the platform, along with the temporary storage of limited datasets for tracking data changes, access (auditing), and tracing (logging). Inevitably, some of this information will include personal data.

Therefore, using the Ometa Framework requires an understanding of the implications concerning privacy laws, such as GDPR.

Data Stored Within the Framework

The following types of data are stored during processing:

User Accounts

When users log in via identity providers (e.g., Windows, Microsoft, or social providers), Ometa automatically collects and processes the following personal data:

  • Email Address
  • First Name
  • Last Name
  • Optional group information (Microsoft 365, Security, Mail-enabled security and/or distribution), only when configured on the Microsoft Identity Provider.

This applies only when Identity Providers are configured.

Optional Group Information

The Ometa Framework requires the Directory.Read.All permission within Microsoft Entra ID to retrieve group information. This permission is essential for securely managing access and authorization within the Ometa Framework. It's important to understand why this permission is necessary and how it is used responsibly.

Why is Directory.Read.All needed? The Ometa Framework leverages group memberships from your existing Microsoft Entra ID to streamline user authorization. By knowing a user's group affiliations, the Ometa Framework can efficiently apply pre-defined security policies and access controls, ensuring users only access the resources they are permitted to. This eliminates the need for separate, redundant authorization systems.

The Directory.Read.All permission is specifically used to read the Active Directory (AD) groups for users who are already known and managed within the Ometa Framework.

Just-in-Time Provisioning and Limited Scope: User accounts within the Ometa Framework are created automatically the first time a user attempts to log in. This "just-in-time" provisioning approach is designed with privacy in mind, ensuring accounts are only created for users who actively engage with the system. Upon successful account creation, and only then, the Ometa Framework retrieves the user's group information from Microsoft Entra ID using the Directory.Read.All permission. Crucially, we only access group information for users who have already been provisioned within our system. We do not proactively create accounts for all users in your tenant, nor do we read user or group information for users who have not yet attempted to access the Ometa Framework. This focused approach significantly limits the scope of data accessed.

Background Synchronization for Consistent Access: The group memberships of all provisioned system users are periodically synchronized to ensure authorization policies remain consistently up-to-date. This synchronization is a background process that occurs automatically, even when users are not actively logged in. Due to this requirement for background operation, delegated permissions (which require constant user interaction and re-authentication) are not feasible. The Ometa Framework utilizes access and refresh tokens for continuous operation, minimizing disruptions and maintaining a seamless user experience. Therefore, to facilitate this essential background synchronization, the Directory.Read.All permission is technically necessary, while in practice, we only read group information for the limited set of users already provisioned in the Ometa Framework.

Option to Disable Group Information Fetching: For organizations with specific security or compliance requirements, you have the option to disable the fetching of group information within the Microsoft provider settings of the Ometa Framework. However, it is important to note that disabling this feature will prevent the Ometa Framework from utilizing AD group information within its authorization policies. This may require alternative authorization methods to be configured.

Privacy-Focused Approach: The Ometa Framework is designed with a strong commitment to data privacy. We strive to process personal data minimally and responsibly. The use of Directory.Read.All is carefully considered and implemented only where strictly necessary to provide secure and efficient access management.

Microsoft 365 - External Guests Users

When an external user logs in using their Microsoft account as a guest, they will be prompted to grant consent, sharing the following information to enable access:

  • Email Address
  • First Name
  • Last Name
  • Picture

Please refer to the following screenshot for an example of the user consent prompt how an external user sees this:

External accounts

After the user grants consent, the Ometa Framework automatically processes and stores the following personal data for external guest users:

  • Email Address
  • First Name
  • Last Name

While Microsoft provides access to the profile picture during the consent process, the Ometa Framework does not process or store profile pictures of external guest users. Furthermore, retrieving optional group information using the Directory.Read.All permission is not utilized for external guest accounts. Microsoft Entra ID does not provide access to group information for external guest users in this context.

Preparatory Data

The Ometa Framework facilitates data flow between systems. This data comprises all information necessary for system operation. By default, any stored information is automatically deleted after 24 hours.

Configurable caching on data output is possible within the solution. This cached data could contain sensitive or personal information. Storage occurs only when caching is configured, and the retention period is user-defined.

BAM Logging

BAM logging is used for tracing and monitoring component activities. By default, any personal information within these logs is removed after 15 days.

Audit Trailing

When the customer enables the audit trailing feature, information is stored in the Ometa Framework database. This data will include company data, as the audit trail records both old and new data, enabling the tracking of data changes.

Method Auditing

Similar to audit trailing, method auditing information is stored in the Ometa Framework database when enabled by the customer. The data retention period is configurable by the customer.

Case Management Information

This category includes messages, properties, and employee information. Beyond usage information within messages, case information constitutes of business data, processed and stored on behalf of the customer. The customer determines the data included in a case. For example, employee information is typically a copy of Active Directory (AD) data, and properties contain case state information. The usage information within each message serves the same purpose as the usage information for objects and methods: tracking and monitoring system activities.

All messages are, by default, purged after 30 days (informational messages) and 90 days (error messages), with the exception of messages required for the logbook module, which have a separate retention policy.