SCIM bridge on lambda

Hey @clouder,

You've got some good questions there. Let me try to address them:

I wonder why it isn't possible to publish the code which is used by the op-scim binary

We've had a few conversations on this topic internally before, and while it is something we'd like to do, it is not on any near term roadmap. We love open source at 1Password and would like to open source the code we leverage for our SCIM endpoints, but there exist quite a few expensive steps we will have to take before we can do so. At this time, shipping features, improvements, and fixes to our customers is more important, and so where we spend our time.

Can somebody explain to me exactly what this daemon is doing?

Great question! There are two main parts to the SCIM bridge: the SCIM request relay, plus the confirmation watcher.

As you point out, the former is mostly stateless, translating from IdP sourced SCIM language requests, into 1Password's encryption key-oriented language. That is what enables us to create users and groups, and do the crypto to set them up with their keysets.

The latter part is the confirmation watcher. That is a background agent which runs every five minutes checking for users to confirm. Once any are found, the SCIM bridge carries out the expensive crypto operations to confirm the user and grant them access to shared vaults. This steps is what alleviates the confirmation workload from administrators.

If you want to know more background, I wrote an explainer blog post here: https://blog.1password.com/1password-scim-bridge-explained/

Does it poll the on-prem IDP for new identities and send it to 1pw and therefore it MUST run always ?

Not for the SCIM integrations (that leverages everything I mentioned above) but this is partially how our Google Workspace integration functions! It leverages a number of web hooks plus occasionally reaching out to Google Workspace to make sure we got everything right.

SCIM bridge on lambda

This is something we have explored multiple times, but so far have not yet found the technical right fit. Given the cost savings you point out, plus the on-demand nature of much of a provisioning workload, it remains top of mind. I won't make any promises, but I wouldn't be surprised to see a serverless version of the bridge in the future.

Let me know what further questions you have.

Graham