SCIM Support for vaults and other OP commands

Hi Team!

We've been waiting to start using the 1P SCIM Bridge at its fullest until we can use it for full access management, i.e. not just user provisioning but also a process like this one:

  • Create Vault
  • Create Group
  • Add Group to Vault
  • Add User to Group

Which is basically the full access management "cycle" in our case, if you will, at least for granting access.

Now, the SCIM bridge hasn't supported these actions for a while. We started two years ago and left this for what it is, assuming these would be implemented in the future. I was hopeful when finding this post mentioning similarities between op and the SCIM bridge, thinking I maybe had missed something, but alas, it's currently still not supported.

At least, that's what I'm deducing from querying, where only Users and Groups are returned as resources.

I was wondering, given the supposed closeness of the development of op and the SCIM bridge, whether this is something to be expected soon? We can always "fall back" to using op, but that would be a significant inconvenience for obvious reasons like the availability of the tool on platforms like Cloud Functions.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided


  • Hi @TimothyVermeiren,

    Those are good questions!

    You are correct in reading that there is a lot of shared code between op, the command line client, and the SCIM bridge. While the two tools share a common code base, the two differ in purpose and neither is meant to be a true API.

    Specifically the command line tool is supposed to be a command line interface to our system, supporting similar actions which you would find in our other client application. This contrasts with the SCIM bridge which is meant to support the SCIM protocol for provisioning actions. For the SCIM bridge, it is an implementation of the SCIM protocol as defined in RFC 7643. As you pointed out, that RFC defines the default resources of User and Group which we support. As vault management falls outside of the the SCIM protocol, it is not something we have seriously considered adding to the SCIM bridge; the identity providers to which it is designed to talk have no concept of a 'vault', only users, and groups.

    That being said, we are alway open to new ideas and to change! Can you tell me a little more about your use case and how the ability to create and manage vaults would impact your provisioning workflow?


  • TimothyVermeiren
    Community Member

    Hi Graham! Thanks for your answer. That actually makes a lot of sense. I understand that you're following the SCIM protocol as defined and that that is the reason why other actions are not in there.

    For what it's worth, in our case, it would have been interesting to have the ability to use the SCIM bridge because it removes the dependency on a tool to be installed locally, op in this case. The reason why this is necessary in our workflow, is because we use to for storing clients' credentials. When someone working for our company starts working for a client, this may be a completely new one in which case the vault still needs to be created, and a group assigned to it.

    That being said, I do suppose we can achieve the same with the command-line tool at this point. It wasn't possible two years ago, I think, but I think it is now.

  • Hi @TimothyVermeiren

    Thanks for sharing your use case!

    One follow-up questions for you: is your 'add a new vault to the new group' workflow true for all of your groups? In other words, when your IDP creates a group, you always follow up and create a vault? Or is this just true in some cases? (EG: not for assigning your engineering team to 1Password, but it is for assigning a new Client Group)

    In either case, you've given me something to mull over.

    I'm glad to hear the CLI will work for now. We have put a lot of time and energy into making it much more fully featured than it was two years ago. If there are features missing there which would be beneficial, I'm sure the team behind it would love to know!


  • TimothyVermeiren
    Community Member

    Hi Graham,

    It's true in virtually all cases. We use vaults for internal purposes too, such as the case you bring up for the engineering team or similar scenarios. This specific authorization workflow is all about client work, though. We don't apply it for internal resources, accesses and items. That happens ad-hoc, currently.

    In any case, thanks for your responsive and helpful approach. We appreciate the improvements you and the team have brought us over the last few years.

  • No trouble at all Timothy. We try to do a good job :wink:

    Let us know if you have any further questions!

This discussion has been closed.