SAML integration for 1Password login



  • Assuming that I'm interpreting what you're describing correctly, this is an idea we've considered and haven't yet ruled out. We look at it as "SAML as MFA". In addition to providing a means of MFA, it would also give a good entry point for automatic deprovisioning if the SAML payload can contain a signed signal for it. It's a neat idea, but since it doesn't provide either provisioning or SSO, the majority of the benefits of SAML aren't there.

    You can't really get SSO for your use case / model. I mean, ok with an "auth bridge" as was proposed you can, but that is horrible solution. Provisioning can come via SAML (eg dashlane does this) but often is easier via a different route. Whatever provisioning you have today (sorry that I don't know what that is) isn't displaced by SAML if you're not able to integrate provisioning. Allowing SAML doesn't remove those things from your existing offering, so it's not a tradeoff situation. Adding SAML is only a benefit, even if all the possible capabilities aren't exercised.

    You already have a similar solution with Duo integration. Duo also doesn't do any of the things you are citing, yet it has value. I find your resistance to SAML puzzling by itself, but especially so in light of your Duo support. For my specific use case, I want SAML so as to (1) enforce a non-Duo MFA requirement, (2) have better assurance that my users aren't stashing a credential and avoiding regular interactive auth, and (3) to have a single console where I can disable users. Automatic provisioning would be nice but isn't a requirement for me.

    I suspect that you don't understand how we use SRP. I recommend that you read my blog post that goes into a bit of detail about how we use SRP. It'll hopefully clear things up for you.

    I read that before posting. I do understand SRP and how you use it. I've implemented it myself ages ago (the details haven't changed since then) in a couple of projects. I didn't say it doesn't have value. I said it doesn't have value to protect against TLS snooping in the enterprise setting, which is what @brenty claimed.

    Not that it matters, because adding a simplified SAML integration as I propose is orthogonal to and compatible with SRP, without requiring the contortions of an auth bridge, but the actual value of SRP in this context is that you can store a strong verifier, one that can't be brute forced, period. You can still get that value, such as it is, by storing an argon2 verifier and having the client do the argon2 hash and send that over the wire. cf. a normal implementation where the client sends the cleartext password and the server does the hash+compare. We could really get off the rails here and discuss crypto-level tradeoffs, but again, it's moot since I'm not suggesting removing SRP in this proposal.

  • rickfillionrickfillion Junior Member

    Team Member

    Provisioning can come via SAML (eg dashlane does this) but often is easier via a different route.

    What Dashlane does with SAML for provisioning is interesting. It doesn't quite work for us though. Provisioning a user with 1Password is a two step process:
    1. The invitation/join process where the use sets up their encryption keys and Master Password. This could be triggered via SAML.
    2. The confirmation process where someone with the admin privileges and access to the team private keys confirms the user by encrypting a team private key with the user's public key. This needs to be done by someone that isn't the user, nor us as neither have access to that private key.

    In order to do step two in an automated way, you'd need a process somewhere running as the admin to do step 2.

    As it turns out this is exactly what we do with our current provisioning system: the 1Password SCIM bridge. A lot of (most?) SAML Identity Providers also provide SCIM support.

    For my specific use case, I want SAML so as to (1) enforce a non-Duo MFA requirement, (2) have better assurance that my users aren't stashing a credential and avoiding regular interactive auth, and (3) to have a single console where I can disable users.

    SCIM gives you an answer to 3. 1 doesn't need SAML or anything provisioning related, it just needs elbow grease on our end. I would be curious to hear more about your concerns with 2. What are you trying to protect against there?


  • edited July 2019

    Thanks @rickfillion . I do use AAD so SCIM is an easy and great fit for me then (minus the need to spend more money for the business plan ;) ). I will have to write-off (2) entirely since vaults are synced locally. I admit my use case there is thin and doesn't fit with how 1pw "works". Indeed, this is addressed by the product itself anyway, since it's generally much much easier to use 1pw than to have a local cleartext stash of a password.

    (1) is still left open but given that sync-auth requires knowledge of the secret key, I suppose that is fairly strong for any practical purpose.

  • rickfillionrickfillion Junior Member

    Team Member

    That's great to hear, @J_Jonah_Jameson. :)

    (1) is something I'd like to see us fix. Like I said, it really just requires more work from us, it's not a technical hurdle like some other things. There aren't enough hours in a day. Or as Shiner would tell me: "Rick, you need to hire more." And he's right. :)


  • Are 1Password working on a SCIM implementation that can be directly joined to an IDp like Onelogin/Okta?
    We really don't want to have to stand up micro instances to enable this kind of integration.


  • rickfillionrickfillion Junior Member

    Team Member

    Hi @apercy,

    No, 1Password cannot be directly linked to an IdP like Okta. Integration with an IdP requires the 1Password SCIM bridge, and that's a good thing. The reason that it can't be directly linked is because actions such as provisioning a new user, or managing group memberships actually requires access to private encryption keys that you (the customer) have that we (1Password) do not. Adding a user to a group isn't simply a matter of associating user X with group Y. It requires that group Y's private key be encrypted with user X's public key.

    The good news is that managing the 1Password SCIM bridge doesn't need to be laborious, difficult, or even time consuming. We have a guide on setting it up via the Google Cloud Platform Marketplace which only takes a few minutes:

    We're always looking for ways to make management of the SCIM bridge easier. It's pretty easy today, but we understand that asking someone to run a bridge service like this is a tall ask. I believe that the security benefits of doing it this way far outweigh the inconvenience, and we're going to keep working to reduce the amount of inconvenience associated with it.


  • rickfillionrickfillion Junior Member

    Team Member

    If GCP isn't your thing and might prefer Digital Ocean, we also have a one-click deployment option for the 1Password SCIM bridge available there:


  • can Sailpoint ID integrate with 1Password SCIM bridge or just okta and adfs ?

  • didn't look hard enough looks doable , why do we need a bridge to use scim though ? seems a bit unproductive

  • BenBen AWS Team

    Team Member

    Hi @tarnould

    I believe Rick addressed that question here. To summarize: the bridge is required due to the security benefits that it provides.


  • Please note, that if you are trying to implement this with Okta, 1password SCIM requires you to have Provisioning features in Okta which is a separate feature you have to pay for. Also, not sure why AWS instructions are not provided as well as this is a major Cloud provider.

  • cohixcohix

    Team Member

    @chadminop There are instructions for AWS here, in the examples repo:

  • Anyone done this with Onelogin? or any idea when a connector will be made?

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file