Overview

Data security and identity management have long operated in separate worlds.

IAM systems like Okta and Entra ID are excellent at defining who can access an application, but they’ve traditionally had no authority over who can touch or transform the sensitive data inside those systems.

Ubiq closes that gap by integrating with enterprise Identity Providers (IdPs) such as Okta and Microsoft Entra ID using the SCIM (System for Cross-domain Identity Management) standard, which extends your existing identity and access management (IAM) policies directly to the data layer.

This integration allows your existing identity and access management (IAM) system to directly govern who can encrypt, decrypt, tokenize, or mask data, ensuring that data-level cryptographic access follows the same user, group, and role policies already managed in your organization.

In short, Ubiq extends your IAM policies down to the data layer, so cryptographic operations are automatically tied to identity.

Why it matters

Modern enterprises are built on two pillars of control (identity and data) but these have evolved in isolation.

Traditional Challenge

IAM has historically been owned by IT and, more recently, security teams, focused on defining who can access systems and applications. Data protection, on the other hand, has been owned by DBAs, data engineers, and infrastructure teams, responsible for securing data at rest using tools like TDE, disk encryption, or storage-layer controls.

These worlds rarely intersect. As a result:

• Access to applications is tightly managed, but access to the data itself often isn’t.
• Cryptographic tools maintain their own user stores, keys, and policies, detached from enterprise IAM.
• Least-privilege principles can’t be enforced at the data level, and access drift becomes inevitable.

Our Philosophy

Ubiq is built on the principle that IAM should govern cryptographic data access controls. If Okta or Entra ID already decides who can log in, those same systems should decide who can perform a cryptographic operation on a specific dataset, even down to a single record if needed.

This alignment closes a long-standing organizational and technical gap: IAM remains the source of truth, while cryptographic enforcement happens directly where sensitive data lives.

By connecting to your IdP via SCIM, Ubiq makes this practical, automatically syncing users and groups, and applying IAM-driven access policies to every cryptographic operation across your environment.

How it works

Integrating your Identity Provider (IdP) with Ubiq fundamentally changes how access to sensitive data is controlled. Instead of managing cryptographic permissions separately (through local database roles, service accounts, or manually issued keys) Ubiq uses SCIM to make your IdP the single authority for all data-level access decisions.

When connected, Ubiq automatically synchronizes users and groups from your IdP, maps them to dataset groups inside Ubiq, and enforces access at the time of every cryptographic operation (encrypt, decrypt, tokenize, mask).

This creates a continuous chain of control from identity → policy → data, ensuring that data protection always reflects your current organizational structure, group assignments, and least-privilege rules.

Identity → Data Policy Synchronization

Benefits

A Unified Model for Identity and Data Security

Every security organization faces the same tension: IAM teams govern access to systems, while data teams govern access to information. The result is two disconnected control planes, one for identity, one for data.

Ubiq bridges those worlds by letting IAM directly govern data protection.

When your IdP dictates who can perform encryption, tokenization, or masking, access becomes consistent, traceable, and automatically aligned with your company’s security posture.

Key advantages include:

• Unified Control: Extend IAM from application access to data access, one consistent identity model across systems.
• Automated Lifecycle: Changes in your IdP instantly update Ubiq access policies; onboarding and offboarding are automatic.
• Least Privilege by Default: Only users in approved IdP groups can perform cryptographic operations on specific datasets.
• Operational Efficiency: Eliminate manual key management for individuals and reduce administrative overhead.
• Compliance Alignment: Every encryption, decryption, or masking event is logged with identity context for audit and compliance.

Typical Deployment Patterns

Scaling Identity-Driven Access Across Teams and Systems

Identity-driven data access doesn’t have to be complex.

Most organizations start with a simple pattern: mapping existing IdP groups (departments, roles, or projects) to Ubiq dataset groups, then gradually expanding to include more granular datasets or workloads. This approach scales cleanly as environments grow, without additional infrastructure or policy sprawl.

Department-Level Integration

• Each department or business function (e.g., Finance, HR, Analytics) maps to a corresponding group in the IdP.
• When those groups sync into Ubiq, access to sensitive datasets is automatically aligned to department membership.

Hybrid Model

• User-level access is governed by the IdP, while non-human workloads (such as services, batch jobs, or pipelines) use Ubiq-managed API keys.
• This ensures consistent identity enforcement for people, while maintaining flexibility for automated systems.

The result is a model where people access policy lives in IAM, and system access policy lives in code, both centrally managed, both traceable.

Security and Operational Considerations

Designing for Scale and Resilience

Integrating IAM into the cryptographic layer brings tremendous advantages, but it also introduces a new layer of responsibility: your data protection model now inherits the strengths and weaknesses of your IAM posture.

Well-defined processes for provisioning, secret rotation, and group hygiene are critical to maintaining predictable, secure behavior at scale.

Best practices include:

• Protect and Rotate Secrets: Rotate SCIM tokens periodically and restrict access by IP or network policy.
• Align Naming Conventions: Keep Ubiq dataset group names consistent with IdP group structures to avoid confusion.
• Review Group Membership Regularly: Overly broad groups can lead to unintended data access; apply least-privilege principles.
• Audit Access Frequently: Ubiq’s logs show who performed each cryptographic operation, with timestamps and identity context.
• Define a Fallback Model: For emergency or break-glass scenarios, maintain one restricted admin key under dual control.

Summary

Extending IAM Control to the Cryptographic Layer

Historically, the teams that controlled who could access an application were not the same as those controlling who could access or protect the underlying data. That separation made least-privilege access nearly impossible to enforce.

Ubiq changes that.

By integrating directly with your IdP, it lets existing IAM policies extend into the cryptographic layer, ensuring that every encryption, tokenization, and masking action is governed by identity.

Identity becomes the common language across security, data, and infrastructure, unifying them under one governance model.

That’s how organizations finally close the loop between who you are, what you can access, and what you can do with the data itself.