SAML integration for 1Password login

J_Jonah_Jameson

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.

rickfillion

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

J_Jonah_Jameson

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.

rickfillion

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

apercy

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.

Thanks

rickfillion

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:
https://support.1password.com/scim-deploy-gcp/

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.

Rick

rickfillion

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:
https://support.1password.com/scim-deploy-digitalocean/

Rick

tarnould

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

tarnould

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

Ben

Hi @tarnould

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

Ben

chadminop

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.

cohix

@chadminop There are instructions for AWS here, in the examples repo: https://github.com/1Password/scim-examples/tree/master/aws-terraform

tstott

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

Ben

Hi @tstott

OneLogin actually just recently featured our CEO Jeff Shiner on their blog, talking about 1Password+OneLogin:

Automated Provisioning: OneLogin + 1Password | OneLogin Blog

We also have a guide on our support site that may be helpful:

Connect OneLogin to the 1Password SCIM bridge

I hope that helps!

Ben

travis_gravitational

I appreciate 1passwords commitment to security but after reading this thread it feels like it really comes at the cost of what users want. I would be fine having the IdP have access to users encryption secrets, most users don't secure them well anyways and we already trust our IdP with access to our production servers.

Ben

Hi @travis_gravitational

I understand the perspective. We’ve positioned ourselves as a leader in the industry in terms of security. People and companies trust us to keep their most sensitive data safe, and so implementing features that run against the grain of that is something we have to be very careful about.

Ben

travis_gravitational

Thanks for the reply Ben. I know you don't want to compromise security and I commend that but I hope 1password can come up with a way that satisfies what business users want, a process that makes account set up and sign-in smooth and well integrated with the IDP in a clever way that does not sacrifice security. At several of the companies I worked at employees view 1password needing a password to login where everything is just one click on the SSO portal as a downside. From an admin perspective dealing with password resets and forgotten secrets makes 1password more work to manage than most other apps. 1password clearly has a very smart team, I'm hoping ya'll come up with something thats the best of both worlds. If a sacrifice had to be made I think trusting the IdP more and the users less is one I would gladly take, even if it ended up that admins could get into user vaults that would be fine since users have a separate personal vs work accounts (the account linking feature is fantastic btw). In any case would love to see a future where 1password accounts are accessible from just one click in the SSO portal.

AGAlumB

It's very different from other things you might use "one click" to authenticate with through SSO, as 1Password is not based on authentication but rather encryption. But perhaps there will be something we can do in that vein in the future.