Otherwise, thanks to many providers like Okta and others, SSO should really be a feature provided to smaller tiers nowadays.
We're a small business (2 founders, 3 contractors), and we'd love to use SSO for everything. But we're too small to afford enterprise tiers for things like Slack, Gitlab, etc.
Hopefully this trickles down eventually.
Update: I'd like to add that we provide a SaaS product as well, and have considered adding SSO to the enterprise tier but after much research we can't really find a good reason to restrict it (apart from "everyone else is doing it", and potential manual config).
But both SAML and OpenID connect have discovery protocols. Again, this CAN technically be self-configured by the right customer. But then, maybe the solution is to have a one-time config fee, rather than require a certain tier.
Lower tiers of SaaS products are more-or-less strictly designed for:
- individuals or very small businesses where everyone is friends
- who don't have exacting requirements/audit/traceability/reporting concerns
- who are willing to accept some pain/inconvenience if they use it outside of its design parameters
Credential-sharing services in the age of SSO are a dirty workaround designed to circumvent SaaS product segmentation (which would otherwise cause established companies to effectively subsidise tiny startups). I'm all for hacker philosophy, and perhaps this applies less to your situation than it does to the OP, but I do think the idea of credential-sharing is a horrible kludge that has only risen to prominence because of the specific issue that I mentioned, and which only leads to more problems with things like non-repudiation.
- Sign up for free or with a credit card, but you'll run into problems (or at the very least friction/complications) if you end up trying to use if you something serious
- Speak to a salesperson and have your CFO sign the company up for a long-term strategic partnership.
The examples that you gave are less clear-cut though. Trello Business is $12.50 per month, and supports Google Apps SSO. Trello Enterprise supports general SSO, and costs $20.83 per month. Slack pricing is $6.67/mo for Standard, and $12.50/mo for Plus with SSO. None of these are costs that should really make or break the profitability of a company; considering that the business is using them to generate revenue or to reduce its expenses, how do they compare to other things like property/facilities expenses and employee salaries/benefits?
Many of those cool things take night or weekend to set up and that’s kind of fun to do. Regular patching and potential troubleshooting is the less fun part you get to do when adopting a new app.
For everything else, you can put your services behind i.e. traefik and write a middleware, or use something like caddy which has a plugin for sso.
I have built an API to interact with 1password through its CLI: https://github.com/lettdigital/onepassword-api
The repo also includes an example of how to call the API using AWS Lambda.
The logic to interact with the 1password CLI is wrapped in an SDK, that can be used independently: https://github.com/lettdigital/onepassword-python
When creating an ec2, we call a module that creates a tls key, a keypair and an object in a bucket.
This object creating triggers a lambda that downloads the objects contents, namely the pem key and calls the api to save it to 1password as a document.
This newly created document is available to every member that has access to the vault without having direct access to the bucket itself.
Another use I had was to create credentials for sonarqube automatically. We have a relatively large team on github and wanted to add sonarqube to the stack. What I did was just read every members name, email and username from github, create the respective users using sonarqube api and register their credentials using the sdk. It was trivial then to send them a copy of their credentials, a lot easier and less error prone than doing it by hand.
Many other use cases can be thought. You could implement iam key rotation using this. You could share support credentials for your team using 1password and have automated tools read from the same source.
It really just make everything easier to replicate, integrate and manage using this api or the python sdk. The last thing you want is to screw someones credentials because of a human error (typo, forgot to save the password etc...)
Not totally relevant to the question, but how well does it scale to enterprise? I found the need to create and manage individual access to vaults to be complicated, even at a few users. I can't imagine how you'd manage 1000s of passwords accessed by combinations of 1000s of users, including third-parties, contractors, etc. Are there any better password management solutions in the enterprise space?
But they did recently introduce a CLI here: https://support.1password.com/command-line-getting-started/#...
That makes me optimistic that you could at least do a fair amount of automation around it. I haven't used it myself yet, so I'm not sure how fully featured the cli is
You should just be able to say “give me the password for yahoo.com” but you can’t actually do that.
I wanted to use it to get npm 2FA on the command line and just gave up completely.
EDIT: if someone from 1Password reads this, please reach out. I have good CLI UX experience and would love to help fix it.
You're completely right about the use-case there. One of the things I think we missed the mark on was choosing to expose the full item JSON structure as the default. I think it is important that access to the full item is available, but I think it would have been a much better user experience if we had abstracted that in the default case.
What you've pointed out here is what we are currently working on addressing. Development of the CLI was put on hold for over a year while development of our SCIM bridge was ongoing (they're built on the same codebase). In the past few months, we have ramped up the entire team, and movement has accelerated greatly on the CLI. This is feedback we're well aware of, and we're working hard to address it.
Feel free to post in our discussion forums if you're still willing to have a more extensive conversation: https://discussions.agilebits.com.
I'll give it a spin again too as it's been a while since I tried it last and check out the forums!
A password manager isn’t required here because it much better to control access with SSO. The user can have one password, preferably just logging into their workstation, and then SSO will sign them into whatever apps they are allowed to. Much easier than having a password manager keeping 80-100 passwords.
In the past we used a safe credential manager that our NOC could access to get admin or other management credentials for networking devices when problems occurred. You could use the same for DB or server passwords where you need the text and combine it with a password manager if you can auto fill them. Only use these options for systems that don’t have SSO.
I used Okta at a previous employer; it was good too.
Is single sign-on an option, instead? Something like Okta is a much better experience for less technical users (and, well, engineers too) where possible, and also lets you trivially manage credentials access as people on/off board (no need to rotate credentials if you're worried folk may have written them down on paper somewhere with malicious intent). That said, it doesn't help folk with personal credentials management, which can be useful for good security policy in addition.
1password is my favorite to have around for services that don't support SSO. I like it so much I pay for a family account, even.