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?