Partitions
1. Overview / Introduction
A partition in SBE is a logical container that groups multiple branches under a common security and operational boundary. It serves as a core security boundary: all access control in the platform is enforced at the partition level using attribute-based (ABAC) models.
Partitions are always associated with exactly one data source, ensuring clear mapping of permissions, configurations, and branches within that scope. There is no maximum number of partitions per data source, but partition creation is subject to customizable resource limits .
2. Conceptual Role
Partitions solve the problem of security segmentation and data organization. By acting as the smallest security boundary, they prevent unauthorized cross-access to branches.
They also serve as a structural abstraction of a business or technical domain, representing a secure subset of a data source’s models and metadata.
Without partitions, the platform would lack the ability to isolate datasets, enforce permissions, and prevent privilege escalation across unrelated data domains .
3. Design Rationale
Partitions are designed to integrate tightly with corporate IAM systems (LDAP + Keycloak) so that existing group-based permissions can control SBE resources.
Key design decisions include:
Three fixed scopes (read, write, manage) applied per partition for clear separation of capabilities.
Mutually exclusive scopes (e.g., manage does not imply write) to avoid unintended privilege creep.
Mutable properties – Names and data sources can be changed post-creation, although changes become more complex as partitions accumulate data .
4. Relationship to Other Resources
Branches – Every branch belongs to a partition; partitions act as the parent resource.
Data Sources – Each partition maps to exactly one data source, ensuring consistent schema and ontology context.
Channels – Channels reference partitions to determine applicable access rules.
Security Enforcement – Keycloak tokens and SBE Guard permission evaluators enforce access at the partition level .
5. Conceptual Usage Patterns
Typical usage of partitions includes:
Creation when a new dataset or secure domain is introduced (subject to resource limits).
Assignment of group permissions (read, write, manage) during creation or administration.
Branch operations (publish, refresh, sync, merge, subscribe, archive) scoped within the partition.
Lifecycle – Partitions are created, configured with permissions, actively used for data operations, and may be renamed, re-linked to a different data source, or archived as needed .
6. Common Pitfalls, Misunderstandings, and Troubleshooting
Assuming manage implies write – Scopes are mutually exclusive; explicit assignment is required.
Privilege spillage – Broad read access to a partition can expose sensitive models to unintended users; use subscriptions for controlled sharing.
IAM sync issues – LDAP-to-Keycloak misconfigurations can block users from accessing partitions even if permissions are correctly assigned.