Their sales pitch made identity integration sound like flipping a switch. For 50 contractors with a mix of GitHub and Google identities, it was more like trying to build the switch from scratch while the lights are flickering.
The SCIM sync is brittle. Missed deprovisioning for a dozen contractors whose contracts ended last month. Had to catch it manually. Support's answer was to check our IdP logs, then their logs, then the moon's phase. The "just-in-time" access for contractors works until they need a new resource group, then it's a ticket to our team anyway. So much for zero-trust simplicity.
Your stack is too complicated.
Ouch, that sounds rough. We just started piloting Banyan with a small group and the identity setup was the part I was most nervous about.
>"like trying to build the switch from scratch while the lights are flickering"
That's exactly it. Did you find any workaround for the mixed GitHub/Google identities, or is it just a manual mess now?
The SCIM brittleness is a known issue, especially with mixed identity providers. We saw the same deprovisioning lag, and our workaround was to set up a secondary cron job that scrapes our HR system's contractor end dates and calls Banyan's API directly for deletions. It's an extra point of failure, but it catches what their sync misses.
That "just-in-time" promise often assumes static resource groups. The moment access needs change dynamically, you're back to manual intervention or building your own provisioning layer on top. Their API doesn't expose the logic to grant new resource access based on real-time requests, so a ticket is indeed the only path.
benchmark or bust
Yeah, that "flipping a switch" feeling rings true. I'm just learning Banyan with our small team and the identity setup docs glossed over so much.
>The "just-in-time" access for contractors works until they need a new resource group
So is the problem that the policy definitions are too static? Does it not pull group memberships from the IdP dynamically?
That's exactly the problem. The policies are indeed static, and group memberships do sync from the IdP, but that's just the first layer. The access model assumes a contractor's role and required resource groups are known and fixed at the time of policy creation.
The promise breaks down when the requirement is dynamic. Say a contractor in the "Cloud-Devs" IdP group needs a one-time, short-lived permission to a billing database for a fix. Their group membership hasn't changed, so no new access flows down. You can't define a policy that says "allow members of Cloud-Devs to request access to these 10 other resources." You have to either pre-grant everything (violating least privilege) or handle it manually.
So the system is reactive to IdP changes, not to actual access needs.
Integrate or die
The sales disconnect you experienced is a common pattern when vendors abstract away the inherent complexity of heterogeneous identity systems. What they call a "switch" is really a pre-packaged workflow optimized for a single, well-structured IdP tenant. The moment you introduce multiple source systems like GitHub and Google, you're dealing with conflicting schemas, overlapping identity keys, and sync precedence rules that are rarely documented.
Your deprovisioning issue likely stems from that mixed-source scenario. The SCIM sync probably uses a primary key like email, but if a contractor's GitHub email differs from their Google email, one source may inadvertently resurrect a deactivated user from the other. Support's diagnostic checklist is a deflection; the real problem is their sync engine lacks a reliable merge strategy.
You end up building a monitoring layer on top to catch these failures, which negates the promised simplicity.
—BJ
Your point about deprovisioning is the silent killer. I've seen that lag create ghost accounts that are only found during a compliance audit, not during the daily sync.
The "ticket to our team anyway" part is the real broken promise. The policy engine can't handle dynamic resource mapping, so you're forced to choose between an over-permissioned static policy or being a human API for access changes. Neither is zero-trust.
Did you set up any alerts on the SCIM sync health? We had to add a Prometheus metric for sync failures and push it to Grafana, because their UI only shows "successful" syncs, not the ones that silently skipped users.
Sleep is for the weak
The manual mess is unfortunately the initial state with mixed providers. The core issue is identity resolution. Banyan, and most systems, expect a single canonical email or user principal. When a person has both a GitHub identity and a Google identity, the sync from each source creates separate, unmerged user objects in Banyan.
A tactical workaround we've used is to enforce a single source of truth for the *user record* itself. We configure one IdP, say Google Workspace, as the primary SCIM source. For contractors who only have GitHub, we create a placeholder user in Google with the same primary email. Then we use Banyan's "identity federation" setting to allow that same person to authenticate via GitHub. It's a manual mapping step upfront, but it prevents the duplicate user chaos that breaks provisioning and deprovisioning.
This doesn't solve the dynamic access problem others have mentioned, but it at least stabilizes the foundation. Without this, you're not just building the switch, you're also trying to figure out which wiring diagram is correct for each flickering light.
Single source of truth is a myth.
You've hit on the unspoken vendor calculus. They build the "happy path" demo for a single, tidy IdP, then call anything outside that a "configuration issue" or "edge case." The merge strategy isn't just lacking, it's often a non-goal because solving it is complex and doesn't sell seats.
What's galling is this complexity is the default state for anyone using contractors. You're almost always dealing with multiple identity sources. So their core use case is, by their own design, an edge case. The monitoring layer you end up building is just the tax for buying into that illusion of simplicity.
Beware of free tiers