So, the SCIM bridge. Because provisioning users to your password manager manually is apparently a luxury we can't afford. I've been tasked with evaluating the 1Password SCIM bridge integration with Okta for an upcoming compliance audit. The marketing copy makes it look like a one-click wonder, but we all know that's where the fun begins.
Has anyone here actually stood this up in production? I'm particularly interested in the bits they don't put in the quickstart guide:
* The bridge server itself – are you self-hosting it, or using their managed option? If self-hosted, what's the real resource footprint and patching cadence like?
* The actual attribute mapping. Their docs show a basic `userName` to email mapping. What happens when your Okta `userName` isn't the primary email? Did you have to push custom SAML attributes to make it work?
* Incident response: Has anyone had a sync failure that orphaned or locked out users? What did the postmortem reveal?
I've glanced at the setup, and of course it requires a service account with full admin privileges to your 1Password account. Delightful. A single static token with the keys to the kingdom, just waiting in a config file somewhere.
```yaml
# A snippet from their example config that gives me pause
op_credentials: "eyJ... [redacted]"
scim_server: "0.0.0.0:8082"
```
Let's hear the real talk. Is this a robust piece of infra, or just another ticking time bomb of technical debt?
- Nina
We went with the self-hosted bridge in Kubernetes two years ago. The resource footprint is trivial, maybe 50Mi memory and negligible CPU. The patching cadence is the real issue. They update the container image for the bridge with no pinned tags, just `latest`. You have to pull their changelog and manually check for updates, which feels amateurish for a security product. I scripted a weekly check after we missed an update for three months.
On attribute mapping, you've hit the main pain point. Their default mapping is naive. Our Okta `userName` is an employee ID. We had to create a custom attribute in Okta, map our primary email to it, and push that as the SCIM `userName`. The 1Password side accepted it, but it took a support ticket to confirm the attribute path wasn't wrong. The docs are useless here.
That static admin token is indeed a crown jewel. We treat the bridge config as a secret, not a config map, and the pod runs on a dedicated, locked-down node pool. But it's still a permanent, broad credential. There's no just-in-time privilege elevation. If that token leaks, you're nuking your entire 1Password enterprise account and starting over. They really need a scoped service account role.