SAML integration for 1Password login
Comments
-
Hi @kiyose - Thank you for sharing your request with us. I appreciate you letting us know this is a sticking point to getting 1Password Teams rolled out to your company. Please shoot us an email
sales@1Password.comand reference this discussion and one of my team members will be happy to continue the conversation with you :smile:ref: p/1771
0 -
Hi AB team—
Adding my voice to the request for provisioning/de-provisioning (rather than SSO). G Suite would be welcome, but SCIM even more so, since many enterprise apps are migrating to SCIM for vendor agnosticism and tools like Okta are standardizing on it.0 -
I see the SSO topic coming up again and again. I just want to share a slightly different take on this that may or may not be of interest.
I think historically some products have considered SSO to be a larger enterprise feature and relevant for large head counts. That may have been true some years ago, but IMO not anymore. We are a company of 20 people only. SSO is essential for us, it is just too hard to use the 15 odd cloud services we use if everyone is signing up of their own accord. The maths is simple 15 * 20 = 300 identities to manage if no SSO. We lose control fast of who can access what and when.
The key aspect of SSO that is appealing to me is if I disable an identity within our Identity system, access to all services is revoked everywhere for that person. (soooo good if that included 1Password). :)
So I just want to shout out that even a company of size 20, for which Teams is a dream product, will falter at the lack of SSO in Teams. We tend to shy away from any new product offering from anyone if it doesn't have SSO. That said, we are using Teams now and like it, but I don't like the lack of SSO, nor that it isn't on the roadmap.
And from a technical perspective, everyone is voicing SAML, but we would prefer OpenID Connect please :)
0 -
You're right, and that makes a lot of sense. Thanks so much for sharing your perspective on this, and letting us know your preference. Glad you're enjoying 1Password Teams, but hopefully we'll be able to make this even easier for you in the future. :)
0 -
I have seen several requests about automated de-provisioning of team members.
Some of these use cases could now be handled with 1Password CLI:
https://blog.agilebits.com/2017/09/06/announcing-the-1password-command-line-tool-public-beta/0 -
Weoukd like to use 1Password, but can’t buy a product without SSO either. Some vendors already have it.
0 -
+3 on this from the three Teams accounts I manage for different organizations.
We would NOT be using 1Password Teams if it were not for the DuoSecurity integration and the expectation that it will eventually work with Desktop and maybe even mobile apps.
DuoSecurity also allows us to have GeoIP blocking so that initial authentication has to be down through our corporate VPN's.
1Password Teams 2-Factor encryption is amazing but it is NOT a substitute for 2-Factor authentication.
0 -
@avshch : when you say 'SSO' are you actually talking about Single Sign On, or are you referring to automatic provisioning and deprovisioning which typically comes along for free with Single Sign On? If you're actually talking about Single Sign On, I'd love to hear more about what you're looking for.
Rick
0 -
Hi
Just +1 to this request. Without possibility to use SSO for the product we can't get on-board. We have number of apps to assign to our 100+ employees and while we need password manager, issue of managing additional password for password manager is a big one. Also proper provisioning API to on-board / off-board people and vaults is what we are looking for.
Managing password is one thing but we have some security mechanisms in place for our users through our identity provider which will not be applied here because of lack of SSO.
0 -
Hi @tonyszko,
I can completely understand why automatic/automated provisioning would be a requirement at a certain size. It's definitely something that's on our radar.
That being said, we have no plans to make 1Password connect to an existing identity provider for authentication. SAML does authentication, and that's great... but 1Password needs more than authentication, it needs a derivation of encryption keys, and SAML identity providers aren't able to do that for us. 1Password could (technically) be an identity provider itself, and in some cases that might be a good fit for teams, but it doesn't help others that want it to connect to an existing IdP.
Rick
0 -
I also desperately want us to use 1Password instead of LastPass but can't because we want SAML for automatic provisioning and unenrollment (if not SSO) so that people can lose access to shared vaults when we remove them from the organization. Really unfortunate that you are losing customers over this!
0 -
Thanks for weighing in, @kiyose -- as rick mentioned, we've got a considerably more difficult time integrating SAML in particular (or indeed any version of SSO), because we cannot cede our encryption to a SSO method we not only don't control but can't even examine in detail. That's why there will likely never be a setup that includes SSO having access to your Master Password to decrypt your 1Password data. We're still trying to figure out if there are ways in which we provide interaction with SAML in ways that would be both valuable to users and NOT require us to do what I just described.
0 -
@kiyose - That's what it sounded like you were asking, but I wasn't sure. We're a long way from something like that at this point, and I'm not even sure we want to go there, because we're focused on building and maintaining the best password manager available. Turning 1Password into a SSO, although it seems related or even like a natural progression from what we already do, would be an entirely new, separate set of code and potential security issues for us to manage. I'm not saying we won't ever venture into that territory, but if we appear to move more slowly on certain issues than you're used to (or than people expect), it's usually because we've got to take into account the security and privacy aspects of literally everything we do -- because our customers expect it. We really do appreciate you taking the time to share your wishes with us about what you'd like to see 1Password be able to do in the future. It helps us gauge what users are most interested in -- and we consider every request we receive. Many of the features you see in 1Password today came at least in part from suggestions from the user community, so thanks for being a part of a long tradition of a very active user community. :)
0 -
Another +1 for an integration in some form.
SSO, overlaid with your own authentication, would be helpful at least - so that disabling a user at the SSO provider stops ex-users at the first hurdle, even if enabled users have to go on to enter their Master Password in 1Password. A (de-)provisioning solution somehow would be helpful. Group management would be better still.
But there needs to be something - our team is growing (now at potentially 60 users) and that's just not manageable in a product that claims to support teams.
(For the record, we're using JumpCloud, which provides a SAML identity provider).
0 -
Welcome to the forum, @phildye! Thanks for weighing in. This is a feature that, as you're already aware, you're far from the first to request. And if I haven't been clear in the past, it's one we're actively considering. There are two main aspects to it, to share a little of our thinking with you: the first (as I said in my reply just above) is making sure we do it in a way that maintains the standards of security and usability we demand of ourselves and our users have come to expect. The second is the abundance of ways something like this could be approached.
We've shied away somewhat from creating something that would let users allow existing SSOs to unlock 1Password, because it would mean ceding users' (hopefully) long-and-strong, encryption-based Master Passwords to a potentially less-secure, authentication-based sign in system that would likely require storing users' Master Passwords in some form in order to function. That doesn't mean it won't happen, just that we tend to be allergic by nature to anything that reduces users' security instead of maintaining or improving it.
Adding an SSO component to 1Password itself, though (essentially, making 1Password a sort of SSO of its own), is another matter altogether -- one which would require more work from us but would result in something where we (and you users) could be more certain of the security. Obviously, we're not opposed to doing the work itself on a great new feature -- but it's a bigger project and there are multiple approaches we could take. I still don't have anything to share with you regarding any "sneak peeks" or even timelines on such a feature, as we just don't normally do such things. But let me be as clear as I'm able: this is something we'd like to do, properly -- which means: securely, and in a way that makes sense for the majority of our users who would want such a feature.
Thanks again for being part of a vibrant and engaged user community who are willing to take a bit of their days to come here or send us an email to share what they'd like to see the future of 1Password be -- it's simultaneously enormously helpful to get unsolicited opinions from real-world users, and gratifying to know that people are so passionate about it. Have a great rest of your week!
0 -
Just adding my voice to the SAML request: I've used 1Password personally for a long time, but the lack of directory integration means we won't be using it in a corporate environment.
As to the 2FA argument: I agree that the two are not really the same thing. However, 2FA is another feature that is almost mandatory in a corporate environment (and although Duo is very good - I've used it at a previous company - it would be nice to have more options!).0 -
Welcome to the forum, @skein! Before we go any farther here, I'd like to direct your attention to a couple of posts from our blog. The comment you're referring to (or at least the most-recent one in this thread) is mine, from Feb 7 of this year. Since then, there's been this post introducing 1Password Business (which may have some interesting sections for you regarding provisioning and integration), as well as this post regarding multi-factor authentication. Give those a read and let me know if that addresses any of your issues, or if you have any questions after reading. :)
0 -
Thanks for the links @Lars I went through them and think that I have a better handle on how you do things and difficulties in setting up your product to work with SSO. I'm super happy that you guys have released Azure AD integration for provisioning and deprovisioning via your new SCIM bridge and business product. That takes out one of the really big hurdles that was getting in the way, and makes it possible for me to consider your solution now.
There is however one big issue that I haven't seen anyone mention here that SSO would solve, and one that I don't think has been given enough credence. That is password complexity control on the master password, and how SSO reduces the friction of using the product and the support overhead.
I don't currently see any options to control what my users set on their master password in terms of length, complexity, or ensuring they do not use a password that has been compromised somewhere else. These are all controls that I have have setup in my AD environment, and if you were to roll out a SAML integration, then that would allow me to take advantage of them with your product.
On the SSO front, I think the advantage of having central identity management has been severely downplayed. 1Password is great when dealing with generating, storing, and using passwords online; but in the corporate environment there are a ton of areas where we need authentication such as workstation, server, and device logins that it isn't a good fit for. I can however tie these things into my AD environment, and the fewer passwords I need my users to remember, the more complexity I can demand from them. If I make them use a super long and complex password, but it's literally the only one they need to remember and they only need to login with it on their workstation, then they are actually happier about it than having a ton of separate passwords. This makes it more likely that they will actually use the product, friction goes down, adoption goes up.
All of this would also result in lower admin overhead for myself and my support team as we wouldn't need to be managing 2 long and complex passwords with our users. This was a big enough deal on it's own for you to release the SCIM bridge product to reduce admin overhead on provisioning, deprovisioning, and group management. Additionally, most SAML providers support 2FA in pretty much any permutation I could want. This would allow me to use something other than Duo for my 2FA, put another piece in place, and you wouldn't have to develop anything on your side.
Now I know that you will probably point out that the Master Password complexity isn't as important due to your use of SRP and the App Key, and that there are technical hurdles that are hard to overcome with the way the product works that makes it unlikely that you will ever be able to support SAML.
To comment on those two items, I think that we need to examine what you are doing, the threat model that you are protecting against, and what it looks like in the corporate environments where SSO would be implemented.
I know this is a massive oversimplification on how SRP works, but the main technical hurdle that I can see is that you are needing to do work locally on the master password, app key, salt, and SRP group, send a result to the server, receive a public value back, and then use the private values to calculate the encryption keys that you're going to use. I'm guessing that currently you are using java script in the user's browser to do that local work, or the standalone apps. With SAML there is no such ability to have it perform all that local work, so you would need an application that would do that work for you and authenticate against the SAML provider as an additional step, something similar to the SCIM bridge that we need to setup to use Azure AD integration right now.
Now the threat model that this interaction via SRP is protecting against is interception of the traffic on the wire, and any kind of data breach at the 1Password end. All of this is very very good at protecting the data while it travels from the endpoint to 1Password's servers and back, while also making sure that 1Password never actually has to store my master password, this means there are no secrets for you to loose. Fantastic, this is exactly what we want. However there is one threat model that it does not protect against, and that is a compromise of the endpoint. The endpoint has the app key, it has the salt, it has the SRP group, and it has the master password (probably not storing that last one, but the user has to enter it so it is susceptible to key logging).
In a corporate environment the devices that are most likely to be compromised and have the least protection are my endpoints. Users have bad habits, and they do things they aren't supposed to, either through ignorance, laziness, or in rare occasions, outright maliciousness. These are the things that we have to take into account and try to protect against in a corporate environment. In contrast my servers and other devices are segregated, hardened and much less likely to be compromised. Taking the responsibility for storing the App Key and other material away from the users endpoints, and putting it into a secured server in my data centre takes those important secrets from the insecure endpoints and places them behind multiple layers of security. It also removes the requirement for my users to manage their app keys or master password in any way, and gives me recourse to back them up. It does concentrate all those secrets into one place, but we have a massively increased ability to protect them, which is a better situation in my opinion. The weakest link in any security situation is generally the user, and this would help alleviate that.
The feeling that I get from your product and what I see on the forums is that you come from the perspective of dealing with individual end users, and as such you try to take as much on yourselves and make it as impossible as you can for the individual to mess something up. This unfortunately can result in higher requirements for the end user to manage multiple secrets, and a distrust of anything between you and your end user. In the case of dealing through a corporation's IT you have a local advocate who is going to be more technically competent and better able to understand the risks and reasons for everything. They can take on some of the responsibility in order to reduce the friction for their users, and ultimately result in a more secure setup for the end users.
I apologize for the rather extreme length of this post, I really couldn't think of a way to shorten it and get everything across that I felt I needed to.
TLDR: SAML based SSO for 1Password isn't impossible, and should actually increase your security, give a better end user experience, and reduce Admin overhead over and above the user provisioning, deprovisioning, and group management problem solved by the new SCIM bridge Azure AD integration.
0 -
Hi @Khelbun,
There's quite a lot to unpack in your post, so please forgive me if I forget to address certain things.
Password Complexity Requirements
You're right. 1Password currently has no password complexity requirements. When creating the account we require a Master Password that's at least 10 chars long, but that's it. Let's go over why that is...
The strength of a password isn't based on its complexity, but in how difficult it is to guess. The two are correlated, but not usually in the way that people think. 1Password helps users create strong unique passwords. You can create super strong passwords that are not complex though. Throw enough length at any password recipe and it can be strong. Complexity (as typically defined by requiring different case, numbers, symbols, etc...) helps in that it adds more numbers on the dice so that you need fewer dice. With more complex options, you need less length for the same overall strength. This is the case for any randomly generated password, and 1Password is pretty good at doing the whole random password generation thing. I really love that if you really want, you can get to the number of bits of entropy that went into each password. It's an objective way of measuring strength.
The problem with complexity requirements for Master Passwords is that a Master Password will almost never be randomly generated. We have our password generator available to users when they're creating their Master Password for those that want something that's genuinely randomly generated, but very few users choose to use that. And it's hard to blame them, having a password given to you and needing to memorize it is really difficult. Most users users choose to create their own Master Password. Obviously we want our users to have a Master Password that's as strong as possible for them to remember. Forcing complexity at this point isn't necessarily going to help though. They're human, so telling them "create something complex but memorable" isn't going to result in
6oMp6mT/eLeRaq%UGs, but instead something likeGermanShepherd92!cause in 92 they had a really cute dog. It's got caps, numbers, and a symbol. But is that a complex password? Absolutely not. They'll do their best to conform to the rules, but the result won't necessarily be what you would want.A much better Master Password for this person would be
petting her was like running your hand through a cloud. It doesn't meet anyone's complexity rule requirements... all it has is lower case letters. But for someone who wants to think of their favorite dog every time they sign in somewhere having a passphrase like that is leaps and bounds stronger.We want strong passwords over complex passwords. How complex it is doesn't matter if it's strong.
Password Requirements
Let's set aside complexity for a sec, cause you make some great points and I want to make sure that they're acknowledged.
We allow a user to choose a Master Password that are known to be weak. We could detect that the Master Password has been part of Have I Been Pwned's list of compromised passwords. There would be very real value in 1Password alerting the user of this fact and pushing them to create a new Master Password. I want to see us do something like that. It feels like the right thing to do.
Administratively Dictate Requirements
There would also be value in allowing administrators to dictate some rules for passwords. For example instead of the default 10 char minimum, an admin might say that they need 14 chars. While I don't necessarily think that complexity rules are helpful, there are other options that could help, and I think it'd be nice if it was something an admin could decide for their team.
SAML/SSO
Theoretically, you're right. SAML could in fact be possible. As far as I know in reality it's not possible, but let's go down the theoretical side of things cause it's an interesting topic.
It'd be possible if there was a SAML Identity Provider that knew how to do SRP, had every account's Secret Key and Master Password, and the Identity Provider could generate a session key with the server, derive the Master Unlock Key and SRP x and send both of those down to the client. Unfortunately it'd only have TLS to protect those very valuable secrets with, and we don't like trusting TLS, but let's ignore that for the sake of argument. Once the client gets a hold of MUK and SRPx, it can then communicate with our server and decrypt anything that it needs. If all of those dots could be connected, I do believe it'd be possible.
The SAML Identity Provider would also need to know how to perform encryption key re-encryption in the case of password changes. This isn't hard, but it's just not something SAML Identity Providers typically do.
Every company is going to have different threat considerations, and yours are perfectly valid. For some companies having the Secret Keys stored centrally would make sense. For others (like ourselves) it doesn't.
As far as I know, there is no SAML Identity Provider that would allow me to extend it to know about all of these things. If you know of a way to teach any SAML IdP how to do these things, I'd love to hear it.
Rick
0 -
Hi @rickfillion thanks for the great response, I completely agree that the biggest need in a complexity requirement is length. The new NIST standards basically say the same thing as what you outlined above, making a long memorable passphrase is much better for a user and generally as good or better on the entropy side than a shorter but harder to remember password with extra symbols etc. I look forward to the ability to adjust those requirements for my users when/if it gets added.
The whole not really trusting TLS thing I'm not really understanding, I agree that an additional layer is never bad, but TLS when correctly setup is a proven encryption technology, and it has the advantages of being available pretty much everywhere, having had a huge amount of development time from some of the smartest people in the world put into it, it's being pounded on constantly, and it gives all the same authentication without sending all the secrets thing that you looked to SRP for with the standard Diffie–Hellman key exchange (I was having flashbacks to my cryto courses when I was reading your SRP explanation :) ). Yeah the odd weakness shows up, but they get dealt with very quickly, and really that's the best that we can hope for in anything. Nothing is perfect, and attacks only ever get better, so the best we can get is something that's always being examined and improved/fixed as quickly as possible when an issue is found.
On the SAML side, I agree that SAML itself will not be able to do what you need to get SSO working, you would need something else to do the local work needed in SRP. I was thinking that you could create an application similar to what you've done with the SCIM bridge that would reside on my network, let's call it the Auth Bridge, to do that local work. The Auth Bridge would be able to retrieve the secrets (App Key, Master Password, salt, and SRP Group) stored in either a SQL database, from my AD, or from the SAML provider (probably backed by my AD anyway), and then perform the SRP connection handshake to produce the session encryption key. With this setup you wouldn't need to be doing the authentication portions with the endpoint as that would be handled by SAML and the Auth Bridge, all we would need to send to the endpoint is the session encryption key for use in the connection to your server for the decryption process. In that scenario you could give the option to only make this available if the authentication request came from inside my network so that the secrets are never sent over the internet, or we could tunnel the entire connection through the Auth Bridge so that the session encryption key etc never leaves there. You could also run the new user provisioning process through the Auth Bridge so that it creates a super secure random password for the user's Master Password and then stores it in whatever database gets used to store the secrets. With the Auth Bridge handling the management of the Master Password and App Key you wouldn't need to worry about what happens when the user changes their AD password, as it's only involved in the SAML authentication side, and there shouldn't be any need for them to change the Master Password as the end user never actually gets that information.
I am aware that something like this would require a large amount of development work, and it wouldn't be happening over night. I've also been mainly outlining how you could make it work in a fully on-prem environment, and we're in a decidedly cloud and hybrid world. I mainly focused on the on-prem environment as you seem to distrust TLS and in a hybrid or full cloud environment you would need to trust TLS to tie everything together due to it's availability everywhere.
I'm also not an active developer, so it's entirely possible that I'm wrong, and there's something that I'm not taking into account that would be a full stop roadblock on getting this working. I did a fair bit of schooling in that field, but ended up going down the road of systems admin due to opportunity and enjoyment of the work. I'm interested to see if you think that something like this could solve your problems, and might be considered in the future.
0 -
TLS when correctly setup is a proven encryption technology
TLS is pretty good, and it forms a large part of protections with our 1Password SCIM bridge because of limitations with what we can expect from other services. It wouldn't be too different here with SAML. It's just nice when we can get more than just TLS, and since our job is to worry about security, it's something I felt was important to point out.
Regarding your Auth Bridge idea... this is an approach that I hadn't considered. It's an interesting one, actually. Thanks for taking the time to explain it another way. It'd require a lot of thought to figure out how to get the various systems to play the telephone correctly, but my gut says that there might be something there.
You're right that this would require a large amount of development work, but it's also the closest thing I've seen to a workable idea. We'll noodle on that one.
Thanks @Khelbun. :)
Rick
0 -
@Khelbun: It's also worth noting that it is unfortunately not uncommon for TLS/SSL to be broken completely, especially in a business environment, not because there's anything wrong with TLS, but because a lot of "security" software suites deployed in that environment do this intentionally to provide "HTTPS scanning" functionality to try to prevent users (who often have no control over this, or even knowledge that it is happening) from accessing unsafe content. If we were relying on TLS for security 1Password users could be exposed to security and privacy breaches as a result, and that's not okay. Regardless of how well-intentioned this setup (and those who implement it) may be, it introduces potential for mistakes, misuse, or outright malfeasance, and it's critical that we're not in a situation where 1Password users are silently exposed to risks like that. Whether an actual flaw in TLS is found or configuration renders it ineffective for protecting data in transit, SRP avoids that entirely and allows all of us to at least rest assured that our 1Password data is safe. :)
0 -
Thanks @rickfillion, glad to hear that the suggestion has some merit, and I hope that something can come of it.
I look forward to seeing what more you guys can do.
0 -
Hi @brenty I understand that you are concerned about things of this nature, however there is no reasonable expectation of privacy for an individual on a corporate network. By the very nature of the work that we need to be able to do on data in a corporate environment we need to be able to view, scan, and manage all data that is going across our environment, this includes breaking and scanning TLS and all other traffic as it comes in, or on each endpoint.
Your response shows that you come from a perspective of supporting the individual, and ensuring their data is sacrosanct until it hits their system, which I applaud. However there are two things that you are missing in your argument. The first is that the techniques etc. that you are describing are being done on the endpoint, in that scenario it doesn't matter if I break the connection as it comes in, or if I deal with the data after the endpoint decrypts it, I still have access to the data because I control the endpoint. The second item is that in a corporate scenario, your client is not the end user, it's the business. You absolutely need to ensure that the data is fully protected until it hits my network, but just like an individual, what happens to it after that point is my responsibility. It's just in the case of a corporate network that edge of responsibility is moved out from the endpoint to the edge of my network.
0 -
I don't think a business is actually capable of using an app, so I do believe it still comes down to individuals, ultimately. But I get your point. Thank you for sharing your perspective on this. :)
0 -
I have a much easier approach than "Auth Bridge" for you. Do the SRP exchange as today, but also do a SAML authentication. This presents almost no UX issue to the user on the desktop, since they will always have a valid SAML auth cached. On mobile, YMMV.
@brenty re: TLS snooping. For teams this is not your concern. It actually is ok (from your POV) for passwords to be susceptible to these issues b/c, as @Khelbun said, the user is not the customer. And even if you insist, you cannot prevent the enterprise from simply installing key stealing software. (The enterprise that insists on a snooping proxy has no qualms with this.) We already know from https://www.securityevaluators.com/casestudies/password-manager-hacking/ that 1pw gives access to everything necessary to the enterprise.
Further, you say that SRP protects users from this, but it doesn't. The encryption of the data (1pw claims "Server ignorance", ergo secrets are only decrypted on client), the mixing with a secret key so as not to depend on password complexity, protects users from TLS abuse. Perhaps before you did the secret key mixing, SRP was useful, but at this point, it isn't really.
But anyway, my solution doesn't depend on ripping out SRP. Anyway, you want a "live" password input as the password manager use case is different than the normal SSO/SAML flow use case. So you can continue to use that and not have to special-case exclude the SRP flow for teams. And the SAML admin doesn't have to special-case auth expiration for 1pw -- which most SAML servers can't do anyway.
0 -
I have a much easier approach than "Auth Bridge" for you. Do the SRP exchange as today, but also do a SAML authentication. This presents almost no UX issue to the user on the desktop, since they will always have a valid SAML auth cached. On mobile, YMMV.
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.
Further, you say that SRP protects users from this, but it doesn't. The encryption of the data (1pw claims "Server ignorance", ergo secrets are only decrypted on client), the mixing with a secret key so as not to depend on password complexity, protects users from TLS abuse. Perhaps before you did the secret key mixing, SRP was useful, but at this point, it isn't really.
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.
Rick
0
