from Hacker News

Show HN: Skip the SSO Tax, access your user data with OSS

by mathiasn on 4/11/23, 12:40 PM with 103 comments

• by kdeldycke on 4/11/23, 2:25 PM

  For those wondering what the "SSO Tax" is, it refers to the excessive pricing practiced by SaaS providers to access the SSO feature on their product.

  A documented rant has made the rounds at https://sso.tax , which lists all vendors and their pricing of SSO.

• by dboreham on 4/11/23, 1:46 PM

  I recommend some editing of the readme to clarify the tool's purpose. Initially I thought it might be an AI-generated spoof project since the description made no sense. I think the tool is for the following scenario: you are a manager in an organization where some set of your employees are using some specific SaaS (see list of currently supported SaaS'es below). You would like to see a list of the user accounts for your employees within your company's "domain" in said SaaS, along with some account metadata. This tool extracts that info using the SaaS domain management API.

• by hobs on 4/11/23, 2:13 PM

  Laughs in enterprise pricing... 14 dollars a user a month? Try 250.

  Last time I talked with dbt on their enterprise plan for the Okta integration level they pitched us 3000 user/year with the clear acknowledgement that they just raised their prices 100% on their other tier and were about to do major price increases to their enterprise tier.

• by OliverJones on 4/11/23, 3:35 PM

  I have to say, I understood what this is really fast when I saw the README. It's really a great idea. I'dve been all over it before I :-) :-) retired.

  It's going to save growing companies a fortune, by helping cancel promptly unused money-sucking accounts across the SaaS multiverses.

  I just hope it's easy to use for superbusy founders, tech people now riding a success wave. Because those are often the people who do the account-cleanup job. If this tool is a pain in the *s to use, there's even more time down the hopper.

  It's almost impossible for people like us to teach ourselves to delegate by inflicting pain on ourselves. And saving big money is worth some pain, amirite? Been there. Done that.

  But HERE's an incentive to delegate:

  * grab the most talented devops person you know. * tell them about this open-source project * delegate to them this account-cleanup PITA * invite them to donate time to the open-source project and give them time to do so. * but they still have to do the actual cleanup regularly. * stand back and watch the growth of a REALLY USABLE open source money-leak-hunting project.

  Every single YCombinator portfolio company would benefit from this. You VC guys? Get some really smart interns to work on this too.

• by vegardx on 4/11/23, 2:47 PM

  I've done similar things in terraform in the past. But you eventually end up spending way too much time on it. If the tool isn't value enough for paying the premium, chances are there are other good alternatives, or we don't really need the tool to begin with. I just look at the individual plans as if they're student tickets for a conference.

  Now lets talk about SaaS providers that don't offer any other way than paying by credit card. Not even pre-paying with a wire transfer. If you've ever tried to source a company credit card in a huge organization you know how hard that can be. And no way in hell I'm going to put $10k/month for various services on my personal credit card and expense it every month. It sometimes feel like they don't even want to run a business.

• by cheeseblubber on 4/11/23, 1:54 PM

  The SSO part is a bit confusing since it sounds like the product is letting you download account and permissions data based on your own api key. It might be helpful if you clarify how you can help with the SSO portion of things.

• by hnlmorg on 4/11/23, 5:02 PM

  I really want to like this but the limitations described, requiring an admin account with 2FA disabled, makes this more risky than not using it at all.

  Until those limitations are resolved, if that’s even possible, this feels like an audit hack rather than a security solution.

• by shellcromancer on 4/11/23, 6:12 PM

  Shameless self-plug for an alternative tax that affects operational security and reliability teams: https://audit-logs.tax

  Understanding how your breach impacts me, or detecting how the abuse of your tools are used to impact our organizations shouldn't cost additional money or be gated to only enterprise contracts.

  Happy to take PRs for other vendors logs being added: https://github.com/shellcromancer/audit-log-wall-of-shame

• by ensignavenger on 4/11/23, 2:56 PM

  As one who self-hosts a number of Open Source applications for a small group of family and friends, I would love to have a simple SSO proxy solution. Many "open core" applications don't include SSO in their Open Source offerings, thus locking small non-commercial users like me out of SSO features for my small non-commercial group.

  I don't really need all of the auditing and compliance features this solution seems to currently offer- I just need a simple SSO proxy. If some one wants to build that, it could be a huge help for small non-commercial self-hosters like me.

• by westurner on 4/11/23, 6:20 PM

  https://github.com/doncicuto/glim :

  > Glim is a simple identity access management system that speaks some LDAP and has a REST API to manage users and groups

  "Proxy LDAP to limit scope of access #60" https://github.com/doncicuto/glim/issues/60

• by somegent on 4/11/23, 5:24 PM

  I think your positioning is wrong. The problem this solves is auditing user accounts in SaaS applications. That is a great problem to be solving, and you can position yourself on that! Why talk about 'SSO Tax' when this has nothing to do with SSO?

  There is at least one other 'open' library for solving this problem (https://github.com/ConductorOne/baton).

  However, I like how you're scraping web data for apps that don't have APIs. I've been waiting for someone to do that. That said, I want it built into other tooling I have purchased, so I don't have to implement myself.

• by lozenge on 4/11/23, 1:59 PM

  This is cool, in that it might encourage SaaS providers to reduce the SSO tax. Discouraging security affects all of us whose data is held by other companies (ie everybody). I'm sure you'll get comments that you're being penny wise pound foolish and wasting your time with these hacks. That entirely depends on where your company is located.

  As it supports so few services, putting the list up top in the README would be a good idea, and a quick explanation of what programming languages/methods can be used to add more services. The chances another organisation has picked the same 7 services as you is pretty low.

• by dbdoskey on 4/11/23, 2:30 PM

  I think this is an amazing idea! I am struggling with a similar situation now.

  Anything that will allow to semi-automate this, and get a periodic report that compares this to where the Single Point of Truth for the account list would be amazing.

• by londons_explore on 4/11/23, 2:01 PM

  It'd like some kind of chrome extension that will 'sso-ize' any 3rd party web app.

  Ie. it will create a temporary deadbeef123@your-domain.com email address, use that to sign up to the 3rd party web app and keep the password secret from the user.

  Then, when the user returns to the site, your on-site server provides the auth details for each logon (or even better, logs in for the user and just sets the right cookies).

  For some sites, it will also make sure the user is a member of the right 'team', has access to the right shared documents, has their display name matching their name in the corp database, etc.

• by throwawaaarrgh on 4/11/23, 2:20 PM

  A fintech that can't pay $14 per user? How many employees do you have? "hours per quarter" but it's not worth the money? Where's the problem? Either you spend the money on a few hours of work for an intern or you fork over SSO money.

  SSO isn't a tax. You either need a single method to disable an account across all providers instantly and enforce password policies globally, or you don't. Do the risk vs reward math and then put the line item in your budget. Get a discount or use a reseller to avoid retail.

• by cratermoon on 4/12/23, 3:58 AM

  As someone who has worked with SAML and other authn/authz technologies, I can only say that the reason for the SSO tax is because that stuff is unreasonably complicated and hard to make work. From things like Microsoft's half-baked proprietary version of SAML to the typical company's crappy in-house login system that was thrown together on top of a system built with security as an afterthought, doing SSO is never simple. Security as an afterthought is always way more difficult than if someone had thought about user roles and permission from the beginning. On top of that, even little companies expect to have things like "well, the execs never really log in, so we need to be able to delegate permissions, but only for things the execs want them to do. We can't give them permissions to sign off on bonuses for themselves".

  Knowing what I know, I don't really begrudge any SSO provider their premium pricing.

• by Flipflip79 on 4/11/23, 2:35 PM

  I think using the term "Skip the SSO Tax.." has done a little disservice to you, and I understand why you chose that term, but this is more "Skip the SCIM tax" I think?

  Regardless, I totally understand the use case and I can immediately put this to work for my team - we will likely contribute some recipes too.

  Thanks for sharing!

• by CSDude on 4/11/23, 4:21 PM

  That's what we try to simplify at Resmo. We integrate with 80+ most popular tools a company might be using. Of course there are some we don't cover yet. Only 3 tools requires paid-tier for API access. Also, we list access Login with Google data from your workspace. We gave a central place for you to list the users and their permissions.

  https://resmo.com/saas-discovery

  Then you can do `SELECT * FROM users WHERE mail = 'mustafa@resmo.com'`

• by pulvinar on 4/11/23, 2:12 PM

  “The SSO tax” is the unofficial name for the practice of software vendors significantly upcharging their customers for Single Sign-On.

  (No, it's not Social Security Organization tax...)

• by Nezteb on 4/11/23, 7:48 PM

  As a dev who primarily uses Elixir, I was excited to see that you built OpenOwl with it!

  Out of curiosity, what made you choose Elixir?

  I wanted to use Elixir to build my PDF scraper (https://github.com/Nezteb/scrape-pdf) but didn't want to spend too much time figuring out how to use Playwright from Elixir, so I went with Node. I'll have to borrow some of your methods!

• by distantsounds on 4/11/23, 2:23 PM

  the "SSO tax" is literally the entire SSO product, a solution to a legitimate problem that businesses face and gladly shell out $$$ to not deal with. if your suggestion is to not pay said $$$ and instead roll your own solution, more power to you, but you're not "skipping" the SSO tax, you're simply passing it onto a different team to do the work of what SSO would provide you.

• by alex7734 on 4/12/23, 12:20 PM

  Why don't companies instead of doing this simply say "if you have more than X employees you can only pick the enterprise tier"? Is it illegal or something?

  I mean you could of course lie when signing up but if a company is risk averse enough to use SSO it's probably risk averse enough to not breach contracts.

• by ThePhysicist on 4/11/23, 2:19 PM

  How does that solve the problem SSO typically solves? It seems you're trying to replace it by syncing users from different tools? That seems worse than SSO and is unlikely to be acceptable, as most security certifications require SSO as a best practice, manually syncing users from different tools won't cut it. Also, implementing SAML-based SSO from scratch isn't that difficult, I did it for our enterprise product and it's barely 500 lines of code. However, we had a nice role-based access management in our tool already, so adding SSO was just a matter of mapping SSO data to our internal role models. That part is usually what causes most effort, i.e. fine-grained access control for different parts of your application, SSO just provides the identity and group management layer that you can use as a basis for that.

  Apart from that, SSO is just a handy feature that non-Enterprise customers usually don't need while Enterprise customers do, so it's ideal for differentiating customers. That said an Enterprise edition contains much more than SSO in many cases, e.g. audit logging, containerized deployments, extensive support, etc.. That's what you pay for with an Enterprise offering, the SSO feature is just a small part of that.

• by goldenCeasar on 4/11/23, 2:50 PM

  Hey mathiasn, I totally feel your pain! I work with the same kind of solution and know how everything can get way more complex than people think, I really liked the "recipes" idea for integrations. If you don't mind how about we have a chat?

• by zebroc on 4/11/23, 2:41 PM

  I like the fact that one could use this within a CI/CD pipeline for example.

  Well done, thanks for sharing!

• by api on 4/11/23, 2:06 PM

  The SSO tax exists because it's historically been a roundabout way of segmenting the market into businesses vs. individuals and charging businesses more.

• by thallium205 on 4/11/23, 3:32 PM

  If you all think your vendor’s SSO price tags are bad, you should stay far away from what their healthcare HIPAA prices are.

• by LionTamer on 4/11/23, 5:04 PM

  Love this idea - was considering trying to build something similar recently.