How do we enable SSO/SAML in Keboola and set up roles/permissions for finance, BI, and engineering?

Most teams hit the same wall: you can’t scale AI and analytics if anyone can spin up a workspace with a Google account and nobody knows who changed what. That’s why the real answer to “how do we enable SSO/SAML in Keboola and set up roles/permissions for finance, BI, and engineering?” is: you design identity and access first, then let the automations follow.

Below is a practitioner’s guide to configuring SSO/SAML in Keboola and mapping roles so finance, BI, and engineering move fast—without creating a governance nightmare.

---

Why SSO/SAML and role design matter in Keboola

Keboola runs your full data lifecycle—ingestion, transformation, orchestration, governance, and AI delivery—in one governed environment. That’s powerful, but only if you can:

• Control who gets in (SSO/SAML, SCIM, identity provider policies)
• Control what they can do (roles, permissions, project-level access)
• Prove what they did (audit trails, active metadata, SIEM export)

For finance-heavy organizations (multi-entity, regulated, or both), this isn’t a nice-to-have. You need to show auditors and the CFO’s office that every workflow—from CDC replication to AI-generated transformations—runs under a verified identity and within clear guardrails.

---

High-level design: identity to permissions in Keboola

Before clicking anything, decide on the structure:

1. Identity source

   • IdP: Okta, Azure AD / Entra ID, Google Workspace, Ping, ADFS, etc.
   • Goal: one source of truth for users, MFA, password policies.

2. SSO/SAML configuration

   • Centralized login to Keboola via your IdP.
   • Optional: enforcement of SSO-only access.

3. Group-to-role mapping

   • Use IdP groups (e.g., FINANCE_ANALYST, BI_ENGINEER, DATA_PLATFORM_ADMIN) and map them to Keboola roles.
   • Avoid direct user-level role assignments wherever possible.

4. Project & organization structure

   • Separate projects for Finance, BI/Analytics, Engineering / Platform, or by entity.
   • Use stricter roles in finance projects; more permissive in engineering, but still auditable.

5. Ongoing lifecycle

   • Onboarding/offboarding via IdP (SCIM or group membership).
   • Regular review of permissions and Activity Center insights.

Once this is clear, the technical steps in Keboola become straightforward.

---

Step 1: Prepare your identity provider for SSO/SAML

The exact UI differs (Okta vs Azure AD vs Google), but the SAML requirements are similar. You’ll create an “enterprise application” or “custom SAML app” for Keboola.

1.1 Create a new SAML application

In your IdP:

• Create a New SAML application / Enterprise app:
  • Name: Keboola SSO or Keboola – Production.
  • Optionally, create separate apps per environment (e.g., Keboola Prod / Keboola Dev) if you manage access separately.

You will configure:

• Assertion Consumer Service (ACS) URL – the Keboola SAML endpoint.
• Entity ID / Audience URI – Keboola’s identifier.
• NameID – typically user’s email.
• Attributes / claims – to send roles/groups.

You’ll get these Keboola-specific values from the Keboola UI in the next step.

1.2 Decide attribute strategy

To manage roles and permissions cleanly, standardize attributes:

• NameID:
  user.email (unique, stable identifier)

• Basic attributes (recommended):

  • email / mail → user’s email
  • given_name → first name
  • family_name → last name

• Group/role attribute (for RBAC):

  • Attribute name: groups, roles, or app_roles
  • Value: IdP group names (e.g., FINANCE_VIEW_ONLY, BI_DEVELOPER, DATA_PLATFORM_ADMIN)

You’ll later map these group values to Keboola roles so access is deterministic and auditable.

---

Step 2: Enable SSO/SAML in Keboola

You need to be an organization admin in Keboola to configure SSO.

2.1 Locate SSO/SAML settings in Keboola

In Keboola:

1. Go to your Organization settings.
2. Navigate to Security or SSO / SAML (naming may differ slightly by stack).
3. Select Configure SAML SSO.

Keboola will show you:

• SAML ACS URL (where IdP sends assertions)
• Entity ID / Audience
• Optionally, Metadata URL you can import into the IdP

Copy these and paste them into your IdP’s SAML app configuration.

2.2 Configure Keboola with IdP metadata

From your IdP:

• Download the SAML metadata XML or copy:
  • IdP SSO URL
  • IdP Entity ID
  • X.509 certificate

Back in Keboola SSO settings:

1. Upload the metadata XML or paste:
   • IdP SSO URL
   • IdP Entity ID
   • Certificate
2. Configure:
   • NameID format: emailAddress (recommended)
   • Attribute mappings: which SAML attributes Keboola should use for email, first name, last name, and groups/roles.

2.3 Test the SSO connection safely

Before enforcing SSO for everyone:

1. Use the Test SSO or Initiate login button from Keboola.
2. Log in with a test user that:
   • Exists in your IdP
   • Is assigned to the Keboola SAML app
3. Confirm:
   • The user can log in.
   • The correct email appears.
   • Group/role attributes are received as expected (Keboola UI usually shows what’s mapped in the test).

Do not enforce SSO-only access until at least:

• One admin can log in via SSO
• You’ve verified role mappings for finance, BI, and engineering (see later section)

2.4 Enforce SSO-only access (optional but recommended)

Once SSO is stable:

• In Keboola SSO settings, enable “Require SSO for login” (or similar control).
• Optionally, allow break-glass local admin accounts for disaster recovery—but store credentials securely with a clear access playbook.

This step closes the door on Shadow AI practices like ad hoc user creation and uncontrolled access.

---

Step 3: Design Keboola roles for finance, BI, and engineering

Keboola uses role-based access control (RBAC) at the organization and project levels:

• Organization roles – who can manage projects, SSO, billing, global configuration.
• Project roles – who can build and run Flows, manage credentials, work in SQL/Python Workspaces, publish to Data Catalog, etc.

3.1 Typical role archetypes by domain

Below is a practical role design that works well in multi-entity finance organizations.

Finance

Goal: Let finance teams consume governed data and run predefined automations (e.g., board reports, intercompany reconciliations) without editing definitions.

Typical roles:

• Finance Viewer / Consumer

  • Access: read-only to key projects (e.g., Finance – Consolidation, Finance – Management Reporting)
  • Can:
    • Browse Data Catalog and subscribe to finance data products.
    • View Flow executions and audit logs.
    • Run approved dashboards / reporting flows if exposed via UI or orchestrated tasks.
  • Cannot:
    • Edit transformations, components, or credentials.
    • Create new connections.

• Finance Power User

  • Access: limited write permissions in finance projects (e.g., for mapping tables, reference data).
  • Can:
    • Maintain mapping tables (e.g., chart of accounts, cost center mappings).
    • Trigger runs of finance-specific Flows (e.g., EOM close pipeline).
    • Collaborate with BI/engineering on minor transformation tweaks.
  • Guardrails:
    • No access to global credentials.
    • Cannot change core consolidation logic, CDC configuration, or MCP Server setup.

BI / Analytics

Goal: Let BI build transformations and data models while staying within governed projects and reusable definitions.

Typical roles:

• BI Developer

  • Access: write access to BI/Analytics projects, read access to finance data products.
  • Can:
    • Build SQL transformations, dbt models, and Python scripts in Workspaces.
    • Design and schedule Flows (under organization-level policies).
    • Publish curated data products to Data Catalog.
  • Guardrails:
    • Cannot change organization SSO settings or activity center policies.
    • Limited ability to edit shared credentials (use component-level permissions).

• BI Lead / Analytics Owner

  • Access: similar to BI Developer, but with project-admin capabilities.
  • Can:
    • Approve changes moving from Dev to Prod (using Dev/Prod mode & branching).
    • Own the canonical definitions for metrics and semantic layers.
  • Often mapped to IdP group like BI_LEAD or DATA_PRODUCT_OWNER.

Engineering / Data Platform

Goal: Give engineering the keys to the platform without letting them bypass finance governance or auditability.

Typical roles:

• Platform Admin / Keboola Org Admin

  • Access: full organization-level permissions.
  • Can:
    • Configure SSO, Activity Center, security policies.
    • Create and manage projects (Finance, BI, Sandbox, etc.).
    • Configure Generic components, CDC, Data Streams, and MCP Server policies.
  • Responsibility: ensure deterministic, governed execution and full lineage.

• Data Engineer

  • Access: project admin in engineering-owned projects; collaborator in finance/BI projects.
  • Can:
    • Implement and optimize Flows.
    • Set up new sources via 700+ integrations or Generic REST API connectors.
    • Operationalize AI-assisted build via Keboola MCP Server (e.g., from Cursor).
  • Guardrails:
    • Finance projects might restrict who can alter specific transformations used for reporting.

---

Step 4: Map IdP groups to Keboola roles

With SSO/SAML enabled and roles defined conceptually, connect them.

4.1 Create groups in your IdP

In your IdP (Okta/Azure AD/etc.):

• Create groups like:
  • KBL_FINANCE_VIEWER
  • KBL_FINANCE_POWER_USER
  • KBL_BI_DEVELOPER
  • KBL_BI_LEAD
  • KBL_DATA_ENGINEER
  • KBL_PLATFORM_ADMIN

Assign users to these groups based on their real responsibilities—not job titles. For multi-entity finance, consider adding entity-specific variants:

• KBL_FINANCE_VIEWER_EU
• KBL_FINANCE_VIEWER_US

This lets you separate access to projects like Finance – EU Entities vs Finance – US Entities.

4.2 Expose groups in SAML assertions

In the Keboola SAML app configuration in your IdP:

• Add a group claim:
  • Name: groups (or roles)
  • Filter: only groups prefixed with KBL_ (to avoid sending irrelevant groups).
  • Output: KBL_FINANCE_VIEWER, KBL_BI_DEVELOPER, etc.

Now, every SSO login sends group membership to Keboola.

4.3 Configure group-to-role mapping in Keboola

In Keboola SSO / Security settings:

1. Open the Role mapping or Group mapping section.

2. For each incoming group:

   • KBL_PLATFORM_ADMIN → Organization Admin
   • KBL_DATA_ENGINEER → Project Admin on engineering projects
   • KBL_BI_DEVELOPER → Developer role on BI projects
   • KBL_BI_LEAD → Project Admin on BI projects
   • KBL_FINANCE_POWER_USER → Editor on Finance projects
   • KBL_FINANCE_VIEWER → Viewer on Finance projects

3. Validate:

   • Use a test user from each group.
   • Log in via SSO and check their roles and project access.
   • Confirm they can or cannot:
     • Open Workspaces.
     • Edit Flows.
     • Trigger runs.
     • See Data Catalog entries.

This mapping is where you turn identity policy into operational control.

---

Step 5: Project-level structure for finance, BI, and engineering

Keboola projects are the operational boundary for workspaces, Flows, and credentials. Smart project design massively simplifies role setup.

5.1 Recommended project layout

A common layout for finance/BI/engineering:

• Finance – Consolidation & Reporting
• Finance – Planning & Forecasting (if P&L planning has different owners)
• BI – Core Models & Self-Service
• Engineering – Data Platform / Ingestion
• Sandbox – Exploration / PoC (strictly limited, clear retention rules)

Key ideas:

• Finance projects:

  • Only FINANCE_POWER_USER, FINANCE_VIEWER, BI leads, and engineers as collaborators.
  • Strong Dev/Prod separation: branches, code review, explicit promotion to Prod.
  • Clear ownership of transformations used in board reporting and regulatory outputs.

• BI project:

  • BI Developers and Leads build most transformations, leveraging finance data products.
  • Finance typically gets view access to understand definitions and lineage.

• Engineering project:

  • Data engineers manage high-impact components (CDC, Generic connectors, Data Streams).
  • Finance and BI can use outputs as inputs to their Flows.

5.2 Use Data Catalog for safe data sharing

Instead of giving BI or engineering direct write access into finance projects:

• Publish finance outputs (e.g., consolidated P&L, reconciliation tables) as Data Products in the Data Catalog.
• BI projects subscribe to those products:
  • No duplication: they always work on the latest, governed version.
  • Clear lineage: source → finance transformations → BI models.
• Access is controlled via:
  • Project roles (who can see/subscribe)
  • Data Catalog permissions (who can publish/consume)

This keeps “one glossary, one truth” intact while enabling cross-team collaboration.

---

Step 6: Auditability and monitoring after SSO/role setup

Once SSO/SAML and roles are live, close the loop with monitoring and audit readiness.

6.1 Use Activity Center for 360° visibility

In Keboola’s Activity Center, you can:

• Track:
  • Every Flow execution
  • Every table created/modified
  • Every user action (who ran what, when, and with which token)
• Monitor:
  • Cost and performance per project, user, and Flow
  • Security events, failures, anomalies

For finance, this translates to:

• Evidence for auditors: journal-level traceability from source to report.
• Faster investigation when numbers don’t match: you can trace the data path and execution history in minutes.

6.2 Stream security and audit events to your SIEM

If your security team runs Splunk, Datadog, or an ELK stack:

• Configure Keboola to export security events and logs to your SIEM.
• Let your SOC:
  • Monitor admin logins and SSO-related changes.
  • Alert on suspicious activity (e.g., failed logins, unusual Flow patterns).
  • Correlate Keboola events with IdP and network logs.

This completes the chain: identity (IdP) → access (Keboola roles) → behavior (Keboola logs) → monitoring (SIEM).

---

Step 7: Keep roles aligned with reality

Governance isn’t a one-off project; it’s a process. To avoid permission drift:

1. Review groups quarterly

   • Compare IdP group membership with organizational charts.
   • Remove users from powerful groups (KBL_PLATFORM_ADMIN, KBL_DATA_ENGINEER) if their responsibilities changed.

2. Align with finance controls

   • For critical finance Flows (e.g., monthly consolidation), enforce:
     • Segregation of duties (builder ≠ approver ≠ runner where required).
     • Change management via Dev/Prod branches and code review.

3. Document “who owns what”

   • For each project:
     • Name a Data Owner (often finance for finance projects).
     • Name a Technical Owner (often BI or engineering).
   • Keep this in your internal runbooks and Keboola project descriptions.

4. Continuously tighten Shadow AI risks

   • Restrict token creation and programmatic access.
   • Use Keboola MCP Server so AI tools (Cursor, Windsurf, Claude, ChatGPT) generate and run pipelines inside Keboola’s governed execution—not as untracked scripts on developer laptops.

---

Practical example: a typical setup

To make this concrete, here’s how I’d configure a mid-sized, multi-entity finance team:

• IdP groups:

  • KBL_PLATFORM_ADMIN – 2–3 data platform owners.
  • KBL_DATA_ENGINEER – 3–5 engineers.
  • KBL_BI_LEAD – BI manager and lead analyst.
  • KBL_BI_DEVELOPER – 5–10 BI engineers/analysts.
  • KBL_FINANCE_POWER_USER – 3–5 senior finance analysts / controllers.
  • KBL_FINANCE_VIEWER – 20–50 finance stakeholders and CFO office.

• Project access:

  Project	Platform Admin	Data Engineer	BI Lead/Dev	Finance Power User	Finance Viewer
  Finance – Consolidation & Reporting	Admin	Collaborator	View / limited edit	Edit selective	View
  BI – Core Models & Self-Service	Admin	Collaborator	Admin/Developer	View	View (optional)
  Engineering – Data Platform/Ingestion	Admin	Admin	View	No access	No access
  Sandbox – Exploration / PoC	Admin	Collaborator	Collaborator	Limited or none	None

• SSO/SAML:

  • Enforced for all users.
  • Group attribute groups includes KBL_* groups, mapped to Keboola roles as defined earlier.
  • Activity Center logs exported to SIEM.

This setup typically gets finance to 48h board reporting and a –70% end-of-month agenda, without losing control over who can change the numbers.

---

Final verdict

Enabling SSO/SAML in Keboola and setting up roles for finance, BI, and engineering isn’t just a security checkbox—it’s how you make AI- and data-driven automation safe, explainable, and auditable.

The pattern is:

1. Centralize identity with SSO/SAML from your IdP.
2. Model access as groups, not ad hoc user permissions.
3. Map groups to Keboola roles across finance, BI, and engineering projects.
4. Use the Data Catalog so teams share governed data products, not ad hoc extracts.
5. Monitor everything with Activity Center and SIEM to keep execution deterministic and compliant.

When you can trace every workflow end-to-end—from ingestion to AI-driven transformation to the final board slide—and explain it to an auditor, you know your SSO and role design are doing their job.

---

Next Step

Get Started