Permissions
Foundation implements a sophisticated and flexible permissions system that combines role-based access control (RBAC) with attribute-based refinements to create a highly customizable security model.
Permission Scopes
The platform uses a hierarchical permission model that operates across multiple organizational levels:
Foundation Level: The highest boundary, which refers to each individual platform instance.
Organization Level: Divisions within Foundations (departments, business units, data domains)
Mesh Level: Collaborative spaces where teams share and build data and use cases.
Entity Level: Each data product, data system, data source, ...
Roles
Users cannot be directly assigned policies; they must be assigned roles, which contain the policies. Currently, each role should be assigned only one policy.
The system defines several pre-configured roles, each tailored to specific responsibilities:
Administrative Roles:
IT Superadmin: Full platform control in order to set up Foundation and connect to data sources.
IT OrgUnit Admin: Organizational unit management in order to provide technical support on connection to other systems, user management and data pipelines.
Data Superadmin: Complete data governance and data management control
Data Governance Roles:
CDO: Full visibility across Foundation
Data Owner: Full control over data assets within an Organization
Data Steward: Data quality and governance enforcement within an Organization
Data Mesh Manager: Controls mesh governance and sharing policies
Operational Roles:
ML Model Developer/Manager/Viewer: AI/ML asset management with varying permissions
Data Product Developer/Editor/Viewer: Graduated access levels for data product management
Data Consumer: Can consume data through the APIs
Asset Owner: Can perform read, update and delete actions on the asset they own (data sources, data systems, applications, data products,...)
Policy-Driven Permissions
What makes Foundation's approach particularly powerful is how policies bridge roles and actual permissions. Rather than hard-coding what each role can do, the system uses policies as an intermediary layer:
Roles are assigned policies rather than direct permissions
Policies contain sets of permissions with defined scopes
Permissions can be dynamically adjusted based on contextual attributes
For example, a Data Product Developer role might have different effective permissions based on:
Which organization they belong to
The classification level of the data (public, confidential, restricted)
The specific mesh they're operating within
Time-based constraints or geographical restrictions
Attribute-Based Refinements
The system extends beyond traditional RBAC by incorporating attribute-based access control (ABAC) capabilities. This means permissions can be refined based on:
User attributes: Department, location, clearance level, project assignment
Resource attributes: Data classification, ownership, creation date, business criticality
Environmental attributes: Time of access, network location, device compliance
Action attributes: Read vs. write, bulk operations, export capabilities
Permission Flows In Practice
Consider a typical data sharing scenario:
A user from OrgUnit1 needs access to a data product in Mesh1
Their base role (e.g., Data Product Viewer) is evaluated
Policies associated with that role are checked
Attributes are evaluated (user's org unit, data classification, mesh policies)
The effective permission is calculated and granted/denied
The Mesh Manager can configure whether:
All data products in their mesh are automatically accessible to mesh members
Users need to request individual permissions for each data product
Certain data products require additional approval workflows
Governance Through Flexibility
This flexible model enables sophisticated governance scenarios:
Data sovereignty compliance: Policies can restrict data access based on geographical attributes
Temporal access: Permissions can be time-bound for contractors or project-based work
Dynamic classification: As data classification changes, permissions automatically adjust
Cross-mesh collaboration: When data products from Mesh1 and Mesh2 are shared in Mesh3, both Mesh Managers must approve, and their respective policies are preserved
Enterprise Integration
The system seamlessly integrates with enterprise identity providers through:
SSO Integration: Connect to providers like Azure AD/Entra ID
Group Mapping: Automatically map enterprise user groups to Foundation roles
Attribute Synchronization: Pull user attributes from corporate directories
This architecture ensures that Foundation can enforce fine-grained access control while remaining manageable at scale, adapting to complex organizational structures and regulatory requirements without sacrificing usability or performance.
Last updated