[HN Gopher] Show HN: Skip the SSO Tax, access your user data wit...
___________________________________________________________________
Show HN: Skip the SSO Tax, access your user data with OSS
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?
Author : mathiasn
Score : 174 points
Date : 2023-04-11 12:40 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Nezteb wrote:
| 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!
| LionTamer wrote:
| Love this idea - was considering trying to build something
| similar recently.
| PhLR wrote:
| Thanks! Happy to chat if you want to share some of the ideas
| you had
| somegent wrote:
| 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.
| PhLR wrote:
| 'Auditing user accounts in SaaS applications' is a pretty good
| summary of what the current version is about. The 'SSO-Tax' has
| become a synonym for the extra charges of SaaS vendors in which
| they usually bundle 3rd party SSO, SCIM and SAML.
|
| What other tooling would you want it to integrate with?
| danielmarkbruce wrote:
| Cerby does this. I'm not them, but I know one of the guys
| there.
| pulvinar wrote:
| "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...)
| vegardx wrote:
| 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.
| dbdoskey wrote:
| 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.
| PhLR wrote:
| Great to see that we were not alone with the struggles! Let me
| know if you are up for a quick chat. Would love to learn more
| about your situation and how OpenOwl could help fix it. If you
| are up for it, my contact is in the bio
| cheeseblubber wrote:
| 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.
| mathiasn wrote:
| That's a good point. Indeed there is a technical focus on login
| flows at the moment as this seems like the hardest problem to
| solve. Adding API key flows makes definitely sense though!
| cj wrote:
| In a similar vein, I'm confused by the messaging: "SSO is
| expensive" problem, the "access user data" problem, "centrally
| manage permissions" problem, and "automatic account
| provisioning/deprovisioning" problem.
|
| 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?
| mathiasn wrote:
| Fantastic feedback. Indeed these are distinctive problems.
| For instance, "SSO is expensive" seems to be the root cause
| for the "centrally manage permissions" and "automatic account
| provisioning/deprovisioning" problems. At least when we're
| not talking about enterprises.
|
| 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.
| westurner wrote:
| 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
| hobs wrote:
| 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.
| Spooky23 wrote:
| If you work for a big company you need to play a little bad cop
| with companies like this. They usually only understand pain.
|
| 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.
| hobs wrote:
| I just laughed in their face and said that their product
| wasn't good enough for me to not just spend one week
| implementing the parts I cared about, and I did.
| reitanqild wrote:
| To twist rhe knife, tell them you'll publish the relevant
| parts as open source as well.
| satvikpendem wrote:
| SaaS companies know this too. They'll charge a higher price
| than they're actually looking to get because they know that
| if you provide a concession at every step of the chain of the
| customer (biz dev, salesperson, VP, CTO, CEO, etc) in the
| buying journey, you are more likely to be bought over a
| company who had a lower overall price but didn't provide
| concessions. There are people in procurement who literally
| exist only to extract concessions from the seller.
| goldenCeasar wrote:
| 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?
| mathiasn wrote:
| Sure, feel free to raise a GitHub issue, happy to discuss.
| goldenCeasar wrote:
| Sorry i wasn't clear, I mean talk about the company/career, I
| worked developing IAM for the last 4/5 years and I am looking
| around for new opportunities.
| Flipflip79 wrote:
| 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!
| lozenge wrote:
| 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.
| mathiasn wrote:
| I really hope that companies stop putting SSO/SCIM into a
| separate plan but allow using it in lower plans.
|
| Thanks for the idea. That makes sense. We hope that more
| recipes can be added soon so that there is more coverage for
| everyone.
| londons_explore wrote:
| 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.
| cj wrote:
| Google Workspace can (sort of) do this. Although after
| googling, looks like they're removing support.
|
| Basically it allowed IT Admins to "hide" the password from
| users logging into websites with traditional user/pass login
| flows.
|
| https://support.google.com/a/answer/9178974?hl=en
| [deleted]
| ensignavenger wrote:
| 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.
| WirelessGigabit wrote:
| I used Authelia and use OIDC wherever I can.
| ensignavenger wrote:
| Thanks, I haven't heard of Authelia before, looks like it may
| work well for my use. I see the OIDC provider support is
| considered beta, have you had good luck with it being stable
| and reliable?
| WirelessGigabit wrote:
| Yea have been running since it came out.
|
| 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.
| thallium205 wrote:
| If you all think your vendor's SSO price tags are bad, you should
| stay far away from what their healthcare HIPAA prices are.
| ThePhysicist wrote:
| 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.
| KyeRussell wrote:
| This reads like a something written from the perspective of
| somebody involved in the creation of a SaaS product, but that
| has never actually been involved in _buying_ one.
|
| 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.
| ThePhysicist wrote:
| I'm my own employer, and I'm usually way more passionate
| about writing features in my problem domain than implementing
| SSO & other enterprise features, which BTW are not in any way
| a differentiator or usable as a sales tactic. It's just that
| without SSO you won't be able to sell any enterprise software
| anymore, at least if it's a web-based product. SSO isn't
| something that SaaS startups try to push on enterprises, it's
| rather the inverse.
|
| 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...
| dang wrote:
| Hey, could you please edit out the swipes in your comments?
| You've got some great points here and you obviously know what
| you're talking about, but the first bit and last bit really
| acidify what you're saying.
|
| (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.
| jarym wrote:
| > 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.
|
| 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...
| jjav wrote:
| > as most security certifications require SSO as a best
| practice, manually syncing users from different tools won't cut
| it
|
| 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.
| fiddlerwoaroof wrote:
| > SSO is just a handy feature that non-Enterprise customers
| usually don't need while Enterprise customers do
|
| 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.
| michaelt wrote:
| Eh, practically every service will let you 'log in with
| google' (or equivalent) for free if you're the sort of user
| who prefers that to a password manager.
|
| 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.
| Steltek wrote:
| "Login with X" is terrible because you don't much of a
| choice for X. Google is generally there but maybe I don't
| trust Google as a gatekeeper for everything I do on the
| Internet. I certainly don't trust Facebook, which tends to
| be the #2 spot for the "Login with X" option.
| fiddlerwoaroof wrote:
| It's sort of funny to me that if you go back to the
| timeshare computer systems of the 70s, everyone took for
| granted that you logged into the "network" and then the
| access you had depended on the permissions your user had.
| Today, we log into our computers and then we spend lots of
| time every day juggling credentials for the third party
| services we use. And, to make it worse, companies expect
| you to use various SaaS apps for day-to-day life and then
| block (or the apps just don't provide) all the means to
| automate repetitive tasks.
| throwawaaarrgh wrote:
| 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.
| m1keil wrote:
| I would argue that any company with 3 or more employees needs
| an 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.
| ebiester wrote:
| If it's one tool, it's not a problem. If it's every tool, it
| becomes a problem quickly. I had a tool that moved from
| 300/month to 2,000 a month just for SSO (for our needs.)
| Launchdarkly is just not usable due to the additional price for
| SSO.
|
| It's absolutely a tax if it's the only feature you need.
| varispeed wrote:
| > A fintech that can't pay $14 per user?
|
| There costs add up quickly and it is prohibitive for a small
| business that is not profitable.
| masterjack wrote:
| It'll be that price multiplied by how many SaaS tools you use,
| each of which will have some premium for their Enterprise plan
| supporting SSO, and typically they won't be transparent about
| what the price is or how to sign up for it, so you'll then have
| to go through the steps of negotiating an enterprise plan.
| Spending a few minutes to figure out their API sounds more fun
| Spooky23 wrote:
| Why do you need all of these tools?
|
| 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.
| dboreham wrote:
| 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.
| mathiasn wrote:
| Oh thanks a lot. I updated the repo description. You're right
| with what you think though :-)
| CSDude wrote:
| 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'`
| distantsounds wrote:
| 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.
| Flipflip79 wrote:
| To be fair - if the SSO tax was just a single SKU for adding
| _just_ SSO to the platform and it was a reasonable like $2 - $4
| a user addition, most people wouldn't care. When we refer to
| the SSO tax what we normally mean is that SSO is gated into the
| "Enterprise" category of a tool for some reason, implying that
| only Enterprises use SSO. The difference usually also includes
| other tools that the customer doesn't need (we only want SSO)
| and so the price difference is usually huge. It makes SSO
| unrealistic for non-enterprise size customers.
|
| 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.
| danenania wrote:
| This reflects a trend of smaller and smaller companies using
| SSO, including startups that now use SSO right from the
| beginning because they know that certifications like SOC2 are
| on their roadmap and they want to get best practices in place
| early. In the past, it really was a 99% chance that customers
| wanting SSO were large companies, but that is changing.
|
| 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.
| shellcromancer wrote:
| 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
| OliverJones wrote:
| 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.
| PhLR wrote:
| That's the spirit! Thanks for the kind words.
|
| Indeed, ease of use is incredibly important. After all this is
| a tool that needs to be used non-developer IT admins as well.
| zebroc wrote:
| I like the fact that one could use this within a CI/CD pipeline
| for example.
|
| Well done, thanks for sharing!
| api wrote:
| The SSO tax exists because it's historically been a roundabout
| way of segmenting the market into businesses vs. individuals and
| charging businesses more.
| mathiasn wrote:
| Historically grown indeed ;-) It's fine to segment the market
| with a separate enterprise plan, I agree! I believe "keeping
| security hostage" by only allowing it for way too high prices
| (multiple of previous tier) is not right though.
| kdeldycke wrote:
| 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.
| m463 wrote:
| SSO: Single Sign On
|
| 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,
| /'saem@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)
| [deleted]
| pwarner wrote:
| I always thought this was insane, but now I wonder if "SSO
| Pricing"/tax is just the "real price" and the "Base pricing" is
| really the new free trial? Of course the SSO/real pricing is
| too high, and everyone negotiates it down, but the point is I
| suspect the "base pricing" is just a trial teaser that's
| probably not sustainable for many vendors in terms of margins.
| I'm just guessing here, maybe someone with some inside insight
| from one of these vendors can advise.
| bks wrote:
| Great question, and as a vendor with multiple products that
| suffer from an SSO tax here is my $.02
|
| 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.
| mananaysiempre wrote:
| So, uh, is that cost a "SAML is a compatibility minefield
| and requires constant tweaking" cost or a "we need to
| allocate some of our people to figure out the network setup
| together with yours" cost? Or something else entirely?
| PhLR wrote:
| Great approach. Wish there would be more vendors like that.
| This way we wouldn't even need to talk about SSO-Tax,
| availability of SCIM/SAML etc.
| wongarsu wrote:
| I'd rather consider it "SME pricing" vs "Enterprise pricing".
| Typically only companies above a certain size use SSO
| systems, and even larger ones require it for everything.
| Coincidentally bigger companies are also willing to pay more,
| so putting a high price on SSO enables SaaS to profit from
| those deep pockets without pricing themselves out of the
| market for smaller companies.
| ehPReth wrote:
| Things like Google Workspace et al. make it super easy to
| use SSO (ok a bit difficult but usable) even for smaller
| companies and honestly it should be used by basically
| everyone as a core security practice. It's annoying that
| companies charge out the rear end for a basic security
| feature. It'd be like charging to let people use
| 2FA/security keys.. just super stupid/arrogant.
| westurner wrote:
| Schools, colleges, and universities typically have SSO but
| no budget or purchase authority.
| wongarsu wrote:
| Just slap an education discount on it and call it a day.
| There are plenty of reasons to do that anyway, you want
| students to get trained on your software and use it in
| their formative years as much as possible.
|
| 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)
| westurner wrote:
| For a small-scale implementation in a university, open
| core without SSO is no-go: nobody has _any_ money or
| purchase authority.
| mathiasn wrote:
| > Typically only companies above a certain size use SSO
| systems, and even larger ones require it for everything.
|
| 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.
| hnlmorg wrote:
| 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.
| numbsafari wrote:
| Yeah, the current approach basically makes this entirely a non-
| starter for the target audience (eliminate a critical control
| for people for whom critical controls are a pain point).
|
| Uploading your 2FA tokens to a third party is also likely a
| non-starter, sorry.
| mathiasn wrote:
| You don't need to upload your 2FA tokens somewhere.
| Everything runs on your local machine. You can do whatever
| you want there.
| danielmarkbruce wrote:
| Have you looked at Cerby?
| PhLR wrote:
| In future versions it will be possible to do the same with, for
| example, your Google SSO sign-in and 2FA enabled. The reason
| for the limitation is that we simply wanted to get it out into
| the world and see if anybody is as excited about it as we are.
| tracker1 wrote:
| For reference, the azure client, opens a browser for the
| login, which redirects to a dns address that equates to
| "localhost" on a port that will effectively get the final
| auth tokens to the local instance, which then persists and
| shuts down the service. Should be able to do very similar.
___________________________________________________________________
(page generated 2023-04-11 23:00 UTC)