As the former CTO of an Insurtech and Fintech startup I always had the “pleasure” to keep regulators and auditors happy. Think of documenting who has access to what, quarterly access reviews, yearly audits and so on…
Like many others we couldn’t justify the Enterprise-plan for every SaaS tool to simply get access to SSO and SCIM/SAML APIs. For Notion alone the cost would have nearly doubled to $14 per user per month. That’s insane! Mostly unknown to people, SSO Tax also limits access to APIs that are used for managing user access (SCIM/SAML).
This has proven to be an incredibly annoying roadblock that prevented me from doing anything useful with our user data: - You want to download the current list of users and their permissions? Forget about it! - You want to centrally assign user roles and permissions? Good luck with that! - You want to delete user accounts immediately? Yeah right, like that's ever gonna happen!
It literally cost me hours to update our access matrix at the end of every quarter for our access reviews and manually assigning user accounts and permissions.
I figured, there must be a better way than praying to the SaaS gods to miraculously make the SSO Tax disappear (and open up SCIM/SAML along the way). That’s why I sat down a few weeks ago and started building OpenOwl (https://github.com/AccessOwl/open_owl). It allows me to just plug in my user credentials and automatically download user lists, including permissions from SaaS tools.
Granted, OpenOwl is still a work in progress, and it's not perfect. At the moment it's limited to non-SSO login flows and covers only 7 SaaS vendors. My favorite part is that you can configure integrations as “recipes”. The goal was for anybody to be able to add new integrations (IT managers and developers alike). Therefore you ideally don’t even have to write any new code, just tell OpenOwl how the new SaaS vendor works.
What do you think? Have you dealt with manually maintaining a list of users and their permissions? Could this approach get us closer to overcoming parts of the SSO Tax?
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.
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.
(No, it's not Social Security Organization tax...)
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.
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.
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.
A documented rant has made the rounds at https://sso.tax , which lists all vendors and their pricing of SSO.
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.
The marketing seems to jumble those 4 problems into 1 problem when (at least to me) they’re 4 very distinct problems to solve.
That leaves me wondering which of those problems are you truly solving? All 4 or just a subset?
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!
Well done, thanks for sharing!
IMO thats generally what people refer to when they say SSO tax. It isnt discounting that providing SSO requires work, its that its never decoupled from a huge platform upsell.
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.
To summarise your comment, my notes in parentheses:
* This isn’t as good as SSO (I’m sure that OP knows that).
* It doesn’t meet your requirements (I trust OP to know what their requirements are, and I myself have been in situations where this would be useful).
* Implementing SSO from scratch isn’t hard. (That doesn’t mean bupkis to someone that wants to use SSO functionality of a SaaS product that they are subscribed to. Also, I’m highly skeptical of any SSO implementation that was ‘easy’ to write).
* SSO’s usefulness is limited without proper access controls within the product (…yes?)
* Only ‘enterprise’ customers want/need SSO. (This is a clear example of uninspired SaaS companies drooling over the white elephant ‘enterprise’ customer: someone with a bunch of money, that will pay for your value-add crap without batting an eyelid. I’ve worked in plenty of settings that I wouldn’t call “enterprise”, but that would’ve benefited highly from SSO. Unfortunately SSO is always locked behind AT BEST a significantly higher seat cost, but usually with a very high floor, and often behind a “contact sales” funnel. Replace “enterprise” with “business”, because that’s the reality. Then…look at your (probably B2B) SaaS product’s package differentiations, and tell me that you aren’t screwing people).
* Enterprise plans usually come with way more than just SSO (Yes! half the point is that most people don’t want this stuff! It’s mostly shovelware to make it not look so egregious to pay so much more for SSO! You’re right! SSO is a small part of that! So why force people to buy the rest of the stuff if they don’t want it? Oh, that’s right, because you’re lining up behind the other SaaS vampires to prey on basically any organisation of more than 5 people that wants have their ducks in a row).
It really just sounds like you’re trying to justify your employer’s crappy yet common sales tactics, and we’re just coming along for the ride.
This isn’t true, IMO, most people just don’t realize there’s an alternative to one user account per service. We’ve convinced non-enterprise users to use an objectively bad solution of password managers because every SaaS service hides their SSO option behind enterprise pricing.
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.
Thanks for the idea. That makes sense. We hope that more recipes can be added soon so that there is more coverage for everyone.
That's your perspective, but let me try another one: So many SaaS products have a free/low-cost tier that allows people to get basic functionality for nothing or extremely cheaply. Users are clearly not unhappy with this and the vendor gets market share and awareness.
However, there is still a cost - and that cost ends up getting subsidised by commercial customers that have a hard need on a small number of features.
That, and the fact that even 'small' business customers these days make you fill out the same 'security review' forms that they don't understand and never read, can require a lot of hand-holding (especially if they have a procurement or legal person who wants to get their requirements in) and can take forever to do a Proof-of-Concept.
ALL of those things have costs and guess what, they end up being added to those small number of 'must have' features.
That is why a base tier might be free but suddenly you add something like SSO and the cost doubles...
Basically it allowed IT Admins to “hide” the password from users logging into websites with traditional user/pass login flows.
Our customers, which are often regular people working for BigCo that try to solve their own work problems aren't overly fond of SSO either, they just need to implement it as a policy since most companies enforce it from the top. You can debate whether that makes sense but if you're running an organization with tens of thousands of employees then not having a unified authorization & access control solution in place is regarded a bad practice, and for very good reasons. SSO solves many real problems that were extremely painful before, where you'd have either no common authorization at all or would need to write LDAP integrations. For all the flak it gets, SSO is orders of magnitude easier to implement and better at enforcing security best practices.
And the reason most SaaS vendors don't put price tags on their website is that it's extremely hard to do pricing as software integration in most enterprise environments still requires a ton of consulting and bespoke development, so if you e.g. put a 10.000 USD price tag on that you're setting yourself up for failure as you typically won't be able to estimate the integration cost until you've talked to the customer and assessed their needs and their IT environment. Deployments have become better as tools like Docker and Kubernetes become more ubiquituous, but it will still take many months to years in most places.
And writing an SSO implementation isn't difficult thanks to many libraries that are available and that do the heavy lifting. In the end SAML-based SSO isn't much more than reading a metadata document, forwarding a user to an external URL, parsing the response document and verifying its signature and generating a local access token for the user. The complexity lies somewhere else, e.g. in the role mapping and in working around the quirks of the specific SSO environment you encounter. Customers e.g. love to use non-standard fields to map organizations, users will often have inconsistent role and organization mappings, the customer wants to add some additional metadata field etc. etc. etc...
There costs add up quickly and it is prohibitive for a small business that is not profitable.
OpenOwl tries to give transparency over the user permission data in your SaaS tools - independent whether you have SCIM APIs or not. It's read-only though. No automatic account provisioning here.
However, as some of these problems are very close to each other, it could make sense to solve them together. But that's not the intent for OpenOwl.
It's absolutely a tax if it's the only feature you need.
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.
SaaS companies want to charge a lower price to price-sensitive customers like bootstrapping startups, and a higher price to price-insensitive customers like big corporations; and they need some way to draw the line. And the moment you've got time to waste on things like SOC2 that drive you towards SSO - you are a price-insensitive organisation.
https://resmo.com/saas-discovery
Then you can do `SELECT * FROM users WHERE mail = 'mustafa@resmo.com'`
(To be clear: I'm not talking about the "SaaS vampires" bit - it's colorful language that's not targeting anyone in particular; it's flamebait, but not so bad that we'd post a scolding. It's the personal swipes in the first and last sentences that are the problem.)
If you could make your substantive points within the site guidelines, that would be the sweet spot. They're here: https://news.ycombinator.com/newsguidelines.html.
Have the sales team fly in and kick them out, etc. Try to get the highest level people possible engaged, then get unreasonable. All of these folks will report some crazy deal opportunity and their chief sales guy will be at their throats back at home. You’ll get the concession you need. Best advice is to just avoid suppliers like this.
It’s really a cost/time to market comparison between the SaaS and you just using SharePoint or managing some substitute. If you’re proposing to drop $80 u/m for Airtable, there better be a tight business case.
That said, I'd say the trend is overrepresented in places like HN. It's still mostly bigger companies that want SSO, which is why SAAS cos keep using it as a pricing differentiator.
Until those limitations are resolved, if that’s even possible, this feels like an audit hack rather than a security solution.
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.
Indeed, ease of use is incredibly important. After all this is a tool that needs to be used non-developer IT admins as well.
Uploading your 2FA tokens to a third party is also likely a non-starter, sorry.
What other tooling would you want it to integrate with?
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
> 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
Many go even further and just give the product away for free for educational institutions and individual students (Github, Jetbrains and Tableau come to mind as examples)
I believe it's historically grown but it's not true anymore. More companies would use it if they could as this makes your processes way more automated, easier and more secure. Also more companies take security seriously (i.e. more and more companies get ISO27001/SOC2 compliant) but just can't afford the Enterprise prices.
Having taken a couple companies through SOC2, I can say that's not true.
Lots of apps being used by enterprises don't even have support for SSO at all, even if you were willing to pay the tax. Audits can't require you to use something that does not exist. Thus, the manual syncing and comparing is a frequent ritual of audit compliance (and to be fair, is something that should be done regularly even if no auditor is asking for 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.
That's not the problem though, the issue is third party apps that don't want/care to support SSO. You can't go and modify their code.
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!
As a small team we get constant requests to integrate with a customers SAML provider - eventually we just switched to https://workos.com/pricing We explain to our customers that we have a hard cost for the integration and we pass that cost to them directly. The SSO version of our product and our self signup product do the same thing the same way - it's the compliance or risk management requirement mandated by our customers that require that we sell it the way we do. In our case our SSO or Enterprise version is $125 more expensive than the self signup product. Our money is in the product itself not in the SSO.
Back in the day SAML was the only game in town, SSO was an enterprise feature. Nowadays with oAuth/OIDC, this is a no brainer and you can get a basic setup going with plain Google Workplace (Gsuite/Gapps/...) without the need for anything else.
Yet SSO keeps being bundled in the premium feature list of most of the SaaS products out there, costing 10x to 100x more per user.
14$ sounds pity, but when you take it in the equation of "price per slot * total slots * products * 12 months", you can get to some serious numbers even for a small 10 people company.
Notice I said "slots". That's because the nasty trick lots of SaaS do nowadays to boost their profits. They will auto provision a slot when a new user onboards, but when that user account gets removed (with or without SSO), they will keep charging you for the slot until an admin goes and reduces the slot amount by 1. This is something that AccessOWL can help with, I suppose.
What's important is that you follow the releases. Read the logs after you update. Something the configuration format changes.
And there are some rough edges. But those are OIDC related. The actual authentication part is much older and stable.
I've only had issues with a configuration NOT allowing me to sign in. Which I appreciate. I rather have a bug that blocks me vs one that allows me.
And they're pretty responsive on discord.
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.
SCIM: System for Cross-domain Identity Management
System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems.
SAML: Security Assertion Markup Language
Security Assertion Markup Language (SAML, pronounced SAM-el, /ˈsæməl/)[1] is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
https://en.wikipedia.org/wiki/Single_sign-on
https://en.wikipedia.org/wiki/System_for_Cross-domain_Identi...
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
(if you work at SpaceX, SSO might also mean Single Stage to Orbit, which is lots more exciting - but since Elon banned acronyms maybe it's not used)
Knowing what I know, I don't really begrudge any SSO provider their premium pricing.
Everybody deserves sso, regardless of size of company.
With the rise of micro services and DevOps, the number of applications used in an org has also exploded, adding even more reason to use SSO. Paying such big markup for every one of them is not sustainable for an SME.
saml has annoyances, but it doesn't have so many annoyances that every customer needs to be a custom integration. the majority of users using saml are going to be coming from a handful of idps, typically adfs or google.
someone used the word on my once i think. 'concession'. they made a 'concession' for me. don't think i twisted their arm or anything.
don't like these games these big players play.
[0] https://www.priceintelligently.com/blog/j-c-penny-s-pricing-...
We use Google SSO at work, but I am just a user. Not involved either budgetwise or implementationwise.
But yeah I was thinking longer about it as Playwright is pretty good for scraping/RPA and works best with Node. One (expected) limitation is that we cannot easily open a browser window to let the user enter a OTP or solve a captcha as we encapsulated everything into Docker. Not sure how we can solve it yet...
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.
I am also from a SaaS vendor and we are using a 3rd party to integrate to the various SSO providers our customers have. We have not tacked on any additional cost to our customers for this as we also believe this to be baseline. But I do like the approach of at least covering costs.
For us it was not a matter of "not being bothered to implement saml in-house". We carefully considered our options. However, implementing it ourselves means we must have an in house expert on SAML and understanding the various IDPs.
It also requires someone to tightly monitoring any security issues that may appear in the wild that could impact our implementation. (We do still need to keep our eyes open, but we can leverage our vendor for help here.)
Resources required to this ourselves is a minimum of at least 1 full time engineer and someone who can be their backup, we need additional testing resources, and more. Making this roll < full time will hurt you down the road.
I'd rather our people can be focused on the problems our product is built to solve for our customers and then we can work with experts in the SSO space to guide / help us in solving that problem.
On the other hand: the 3rd party we're working with likes to come back every few months with a "Oh! We didn't know you were going to do (fill in the blank), we need to add another dollar per user per month for that."
Neither approach is perfect. But I lean towards keeping our teams as focused as possible on our product.
(PS: I have been with other orgs who've done SAML in house, and it is not simple. Don't underestimate it. It hurt, and we burned a lot of resources that could of been making our product better.)
Can anyone think of any other reasonable product-agnostic criteria other than SSO?
That's why companies don't publish their pricing, to prevent something like this.