Configuring the Marketplace Module
The Marketplace module allows organizations to create a data marketplace around their data products, enabling structured access requests, approvals, and governance. This guide explains how to configure the module, focusing on user roles, provider setup, and custom metadata for access requests.
Marketplace Administrators have also access to several configuration options that allow them to customize the marketplace behavior and control access request workflows. These settings are available in the Marketplace Settings section and provide granular control over how the marketplace operates within your organization.
Understanding the User Personas
Three main user personas interact with the Marketplace, each with distinct roles and responsibilities:
-
Consumer: Requests access to data products through the marketplace. Consumers can browse available data products, submit access requests with required justifications, and manage their existing access permissions. Ideally, they provide clear business cases and intended usage details when requesting access.
-
Provider: Reviews and approves access requests related to specific data products. Providers are responsible for evaluating access requests, ensuring compliance with data governance policies, setting appropriate access levels, and monitoring usage patterns. They also maintain product documentation and handle user inquiries about their data products.
-
Marketplace Administrator: Oversees the entire marketplace configuration, manages roles, and has full access to data and reporting. They configure global marketplace settings, define custom metadata fields, manage user permissions, monitor platform usage metrics, and ensure the marketplace aligns with organizational data governance policies. Administrators can also intervene in access workflows when needed and generate comprehensive usage reports.
Configuring the Provider Role
Users are recognized as Providers for specific data products based on the responsibilities assigned to them. When an access request is submitted, Blindata automatically checks for any defined responsibilities associated with the target data product. These responsibilities determine which users will be notified to review and approve the request. If no responsibilities are configured, no reviewer will be notified, and a warning will be shown to the requester to highlight that the request may remain unattended.
Configuring the Provider role involves two main steps:
- Create a Role for Data Product Responsibilities
- Use the Stewardship module to define a new responsibility role.
- Configure the role to apply specifically to Data Product entities.
- Assign users to this role based on their responsibility for managing or stewarding the specific data products.
- Configure the Role in Marketplace Settings
- As a Marketplace Administrator, access the Marketplace Configuration settings.
- Specify the newly created Data Product Manager role as the one responsible for acting as Provider in access workflows.
- This setup ensures that access requests for each data product are automatically routed to the responsible users.
More details about managing role and responsabilities can be found in the dedicated Stewardship & Responsabilities Guide .
Info
If no responsibilities are configured for a data product, access requests can still be created, but no Provider will be notified to review the request. In this case, a warning is displayed to the requester, informing them that the request may remain unattended until responsibilities are properly assigned.
Publishing Configuration
The Publishing Configuration feature provides granular control over which data product ports can receive access requests in the marketplace. This powerful capability allows Marketplace Administrators to implement selective access control at the port level, ensuring that only appropriately configured data products are available for access requests.
This configuration operates through a custom property system that Providers can set on their data product ports. When enabled, the marketplace checks for a specific property on each port to determine whether it should be available for access requests. This creates a two-tier control system:
- Administrative Control: Marketplace Administrators define the property name, default value, and true value
- Provider Control: Individual Providers can then set this property on their ports to control availability
Marketplace Administrators must configure three essential parameters:
-
Property Name: The name of the additional property to check on data product ports. This property must be defined on the ports where you want to control request availability. Choose a descriptive name that clearly indicates the property’s purpose (e.g.,
Marketplace Enabled
,Access Requests allowed
). -
Default Value: The default value to use when the property is not defined on a port. This determines whether ports without the property are requestable by default. This setting provides a safety net for existing ports that haven’t been updated with the new property.
-
True Value: The value that enables the port to receive marketplace requests. Only ports with this property set to the specified value will be available for access requests. This value should be distinct and meaningful (e.g.,
True
,Enabled
,Yes
,Requestable
).
Use Cases and Benefits:
This configuration is particularly valuable for organizations that need to:
- Gradually Roll Out Marketplace Features: Start with a limited set of data products before expanding to the entire catalog
- Compliance Requirements: Ensure only data products that meet specific compliance criteria are available for requests
- Quality Control: Allow only data products that have been properly documented and validated to appear in the marketplace
- Departmental Control: Enable different departments to control their own data product availability independently
Info
By default, if no settings are provided, all ports are requestable. This configuration provides a way to implement selective access control at the port level.
To enable selective access control at the port level, you must provide all three configuration values.
Warning
Once this configuration is enabled, and the default value differs from the defined “true value”, Providers will need to explicitly set the specified property on their data product ports to make them available in the marketplace. Consider communicating this change to your data product owners to ensure a smooth transition.
Service Account Requirements
The Service Account Requirements configuration allows Marketplace Administrators to enforce specific authentication and access control policies for different consumer types. This feature ensures that organizations can maintain appropriate security standards while providing flexibility for different use cases.
Service accounts are specialized credentials used by applications, services, or automated processes to access data products. Unlike user accounts, service accounts are designed for programmatic access and often have different security requirements and lifecycle management procedures.
Marketplace Administrators can configure service account requirements independently for each consumer type, providing three distinct options:
-
Optional (default): Users can choose whether to provide a service account. This setting offers maximum flexibility and is suitable for organizations that want to encourage but not mandate service account usage.
-
Required: Users must provide a service account to complete the access request. This setting enforces strict security policies and ensures that all access to data products is properly authenticated and traceable.
-
Disabled: Users cannot provide a service account for this consumer type. This setting is useful when organizations want to restrict access to user-based authentication only.
Consumer Type Restrictions
The Consumer Type Restrictions feature provides Marketplace Administrators with the ability to control which consumer types can access the marketplace.
When a consumer type is disabled, users will not be able to create access requests for that consumer type in the marketplace. This restriction applies globally across all data products and affects all users. The restriction is enforced at the marketplace level, ensuring consistent application across the entire platform.
Third-Party Request Restrictions
The Third-Party Request Restrictions feature enables Marketplace Administrators to enforce self-service policies for access requests. This configuration restricts users from creating access requests on behalf of others. For applications, the requester must be the responsible user for the application.
Third-party requests occur when one user attempts to request access for another user or application. While this can be convenient in some scenarios, it can also create security and accountability challenges. This feature allows organizations to control when such requests are permitted.
Third-party request are enabled by default. Marketplace Administrators can enforce restrictions for the follwing consumer types:
- User Access: Users can only request access for their own user accounts. They cannot create requests on behalf of other users.
- Application Access: For application-based access, the requester must be the designated responsible user for that application. This ensures that only authorized individuals can request access for applications.
Adding Custom Metadata to Access Requests
To collect additional information during access requests—such as cost centers or intended purposes of data access—you can configure custom properties for Access Requests:
- Navigate to Settings → Custom Properties.
- Create new custom properties that apply to the Access Request resource.
- Mark fields as mandatory if required, to ensure consistent data collection.
- These additional metadata fields help organizations gain visibility into the purpose and context of data usage.
More details about managing custom properties can be found in the dedicated Custom Properties Guide .
Marketplace Roles and Permissions Overview
The Marketplace permissions model directly reflects the three user personas, with each role having specific permissions aligned with their responsibilities. Consumers are granted basic viewing and request capabilities through MARKETPLACE_VIEWER
, Providers can manage their data products and handle access requests with MARKETPLACE_EDITOR
, and Marketplace Administrators have full control over the platform with MARKETPLACE_ADMIN
. This clear separation ensures that users have the appropriate level of access to perform their designated functions.
Info
To effectively approve and manage access requests, users must have both the MARKETPLACE_EDITOR
permission and be assigned the appropriate responsibility for the target data product. Having only the permission without the corresponding responsibility will not allow users to act as Providers for access requests. Note that users with MARKETPLACE_ADMIN
permission can operate on all access requests regardless of responsibilities.
Role | Permission | Description |
---|---|---|
Consumer | MARKETPLACE_VIEWER |
Can browse the marketplace and request access to data products. |
Provider | MARKETPLACE_EDITOR |
Can review and approve access requests for data products they are responsible for. |
Marketplace Admin | MARKETPLACE_ADMIN |
Full access to marketplace configuration, data, and reporting. Can operate on all access requests regardless of responsibilities. |
For detailed permission mappings, see the Permissions List page.
Integration with External Access Management Systems
For organizations that need to automate access approvals or integrate the Marketplace with existing access management systems (e.g., ticketing systems, identity and access management platforms), the Marketplace module provides an extension point via the Control Plane Service of Open Data Mesh.
This extension point is realized through the Marketplace Executor, which allows you to customize and develop the integration logic required for your specific environment.
A starter project is available at:
➡️ https://github.com/opendatamesh-initiative/odm-platform-adapter-marketplace-executor-starter
You can use this starter as a foundation or choose your preferred technology stack to implement your integration. The only requirement is to conform to the Marketplace Executor API exposed by the platform, ensuring seamless communication between Blindata’s Marketplace and your external systems.
The minimum set of services required to enable this integration includes:
- Notification Service: Handles event delivery and notifications between services.
- Marketplace Service with Executor: Manages access request workflows and delegates execution to a customizable Marketplace Executor.
- Blindata Observer: Connects Blindata to the Open Data Mesh ecosystem and listens for relevant events.
More details can be found in the Data Ops Platform Architecture Overview .