SAML integration for 1Password login

13»

Comments

  • 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?

    Rick

  • edited July 15

    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. :)

    Rick

Leave a Comment

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