JHoelli commented on PR #4074: URL: https://github.com/apache/streampipes/pull/4074#issuecomment-3719605885
# Current Issue When moving permission management for datasets from the Pipeline Manager to the DataLakeResource, we are facing an issue where the principal ID is lost if a data lake is created from a pipeline. This occurs because the getAuthenticatedUserSid() method only returns the user ID of the service principal (sp-service-client), which results in incorrect ownership assignments. On the other hand, when a data lake is created via API, the correct ownership is assigned, as the user token is properly used. Creating a data lake via API results in the correct ownership due to the provided user token. # Possible Solutions ## Move the Measurement Creation to the DataSinkInvocation **Idea:** Split the measurement creation and update process. Only create the measurement and pipeline permissions within the Pipeline Manager. **Pros:** - Separates concerns, keeping pipeline management cleaner. - Allows permissions to be set specifically for the pipeline context. **Cons:** - more complex flow management. - Reusability ## Add an additional Header **Idea:** Introduce a new HTTP header to specify if the authenticated user is an admin. If the user is an admin, allow the system to use the user ID from the token (via TokenAuthenticationFilter) instead of the service principal ID. **Pros:** - Reusable solution for other use cases. - Ensures the correct user ownership. **Cons:** - may be harder to understand. - no other usage of such logic. ## Create Permissions in the Pipeline Manager and only check if Permissions are available in the DataMeasureResource **Idea:** Revert to the old approach: create the permissions in the Pipeline Manager with the authenticated user. In the DataMeasureResource, simply check whether permissions already exist. If not, use the currently authenticated user to set the permission. **Pros:** - Easy to implement. - Ensures functionality with the StreamPipes client and core systems. **Cons:** - Permissions are managed in two separate places, making the implementation less clean. - Reduces reusability, as permission management is not centralized. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
