Having recently concluded a multi-phase, 18-month cloud data platform migration (source systems: on-prem Oracle, target: Snowflake on AWS), I've been conducting a post-implementation review of our supporting security and identity tooling. Our architecture mandated a strict separation of duties between identity management (provisioning, lifecycle) and privileged access management (elevation, session monitoring, audit). We piloted both Glide Identity and Oasis Security in the final stages, ultimately standardizing on one. I'm interested in comparing notes with others who have evaluated or implemented this specific combination.
From my detailed playbook, the theoretical synergy is clear:
* **Glide Identity** handles the core identity governance: Joiner-Mover-Leaver workflows, role mining, access certifications, and SaaS app provisioning via its low-code platform.
* **Oasis Security** then acts as the enforcement and monitoring layer for privileged access, particularly for cloud infrastructure (AWS IAM Roles, GCP Service Accounts), data platforms (Snowflake, BigQuery), and CI/CD pipelines, with a strong focus on Just-In-Time elevation and session recording.
However, the integration in practice presented several nuanced challenges:
**Observed Pros:**
1. **Unified Identity Source:** Once Glide's role catalog was established and synced to our HR system, Oasis could consume those same logical business roles as a basis for its entitlement policies. This created a clean chain of attribution from business function (in Glide) to a temporary, audited privileged session (in Oasis).
2. **Automated Deprovisioning Cascade:** A user termination workflow in Glide could trigger a revocation of the user's standing privileges in Oasis via webhook, effectively eliminating the time-window for misuse after departure.
3. **Detailed Audit Trail:** The combination provides a comprehensive narrative. You can trace a privileged action recorded by Oasis (e.g., `ALTER WAREHOUSE PROD_WH`) back to the access request and certification history in Glide.
**Encountered Cons / Integration Friction:**
1. **Role Definition Misalignment:** Glide's role model is often oriented towards application entitlements (e.g., "Snowflake-Analyst" with READ access to a schema). Oasis requires more granular, task-specific entitlements (e.g., "Snowflake-Warehouse-Resizer" to execute `ALTER WAREHOUSE`). We had to create a mapping layer, which added complexity.
2. **API Latency for JIT:** For a true Just-In-Time workflow, a user's request in Glide needed approval, then the provisioned access (a role) had to sync to the target system (e.g., AWS), *before* Oasis could grant the time-bound elevation. The cumulative API lag sometimes frustrated users expecting near-instant access, requiring careful expectation management and pipeline optimization.
3. **Configuration Overhead:** Maintaining the harmony between the two systems became a non-trivial administrative task. Example: a simple change to a Snowflake role's permissions required a coordinated update in Glide's connector, Oasis's policy, and the mapping between them.
**Key Configuration Snippet (Illustrative):**
Our mapping table, maintained in a small configuration database, looked something like this:
```sql
-- Mapping Glide Business Roles to Oasis Privileged Tasks
CREATE TABLE idm_pam_mapping (
glide_business_role VARCHAR(100),
oasis_entitlement_group VARCHAR(100),
target_system VARCHAR(50),
max_jit_duration_minutes INTEGER
);
-- Example Record:
-- 'Data Engineer', 'snowflake-warehouse-admin', 'SNOWFLAKE_PROD', 120
-- 'Cloud Admin', 'aws-poweruser-access', 'AWS_PROD', 90
```
**Open Questions for the Community:**
* Has anyone developed a more elegant solution for the role/entitlement mapping challenge than a manual lookup table?
* Were you able to achieve a sub-2-minute total latency for JIT access from initial request to usable elevation? If so, what were the critical optimizations?
* Did you leverage Oasis's session recording for compliance, and if yes, how did you correlate those session IDs back to the initiating Glide workflow for audit purposes?
I am particularly interested in experiences from complex, multi-cloud data environments where the privileged access spans both infrastructure (IAM Roles, K8s clusters) and data platforms (queries, DDL execution).
- Mike
Wait, you mentioned integration. That's a big one I'm worried about.
Did you have to build a lot of custom connectors between them, or was it mostly plug-and-play? I'm just starting to look at tools like this and the setup time seems huge.
Also, which one did you standardize on? And... why?
Integration is exactly where the synergy falls apart, in my experience. The marketing slides show a clean handoff, but the reality is you're stitching together two separate products with APIs they don't own or prioritize. That means you're on the hook for building and, more importantly, maintaining that middleware.
The setup time isn't just huge upfront, it's a recurring tax. Every time one vendor updates their API version or changes a data model, you're back in the integration code. The total cost of ownership for this "best of breed" combo gets out of hand quickly, which is likely why OP had to standardize on one. Which one did you pick, by the way? That's the real tell.
That's the big trade-off, isn't it? The clean theory of best-of-breed vs the messy reality of keeping it running.
You said it was mandated, but I'm curious about the decision that *enforced* that architecture separation. Was that a genuine security requirement from a CISO/audit team, or more of a conceptual design choice from the platform architects? Sometimes those mandates are more about theoretical purity than operational cost.
If it's the former, the integration tax might just be a hard cost of doing business. If it's the latter, well, that's where the frustration user644 mentioned really kicks in. You're paying a huge maintenance price for a boundary that maybe didn't need to be so rigid.
MartechMatch