Hacker News Reader

Comment by cebert | Hacker News Reader

How do you implement that with web apps?

Myriad ways, pretty standard on most corporate networks, to restrict access to corporate devices. I cannot access any of my client's resources, including Web apps, without their laptop.

Simple method is IP whitelisting, easy in some ways painful to keep updated. Vpn is another easy option. But then you can have client side certs, hardware tokens, and endpoint security mechanisms which are probably more robust. Either way, it's not a weird unique thing, it's pretty ubiquitous :)

I have to be logged in to azure vpn to access the development environment of the web application I work on because heavens forbid if our users stumble upon a non-production version of the application on the Internet and yet these people just put everything out there for everyone to see. At least I think it should require a CAC card or a PIV card to access sensitive data like this, shutting down immediately if the card presence is not detected somehow.

Due diligence is basically the enemy of the "growth at all costs" mindset.

I think the idea of Flock (and all modern software, pretty much) is not just to offer a service, but to offer it as dirt-cheap and lazily as possible with the intent of creating reasonable margins for a product that otherwise shouldn't even be profitable in the first place.

Doing things, "correctly" is sort of no longer the place of software. The idea is to build solutions that are comprised of toothpicks and sticky tacky so you can force out whatever the alternative was and make money for the shareholders at the same time.

IP range allowlists, mTLS, any number of conditions on your auth provider, take your choice.

I can’t run any web apps from my employer unless I’m on one of their computers. Tokens are only generated on corporate systems. IP access only allowed from corporate VPN.

Probably the department's fault for not using (presumably) Entra Conditional Access to restrict SSO to corporate devices / corporate subnets.

This is why if you're building a product, please give SSO for free (see sso.tax) - you shift responsibility, requirements and posture to the tenant's IdP.

Unfortunately that will make you a lot less money. The whole premise of the sso.tax seems based on that it's not intentional.

It is intentional and deliberate price discrimination to charge enterprises more. One example: why do you think enterprises don't just stack consumer/teams Codex or Claude subs with significant subsidies; given that all enterprise seats are API/PAYG now? SSO/IdP + ability to opt out of training globally

SSO is a core security feature, not a value add. I do not mind charging extra for say SCIM or advanced RBAC. I have a different view to business than most SaaS apps, and feel when you bring value and delight to the customer, they take you as a trustworthy partner and want to grow with you. Trust is very important and I feel so bitter paying Bitwarden, Adobe, and all the other enshittified stacks that 30-100% uplift on the base plan to get SSO. I also love my homelab stuff and it's a sour taste when I need to set up some system with local auth. yeah, maybe some nerd's A/B test show charging SSO makes more money, that's a shame and I think long term it's simply harmful (and probably less profitable due to my comment on stickyness and delighting customers being good business sense).

Only a tech nerd would think the solution to massive overreach by government organizations and illegal use of mass surveillance tools is more technology from one of the participating technology companies...

Could you use SSO as a layer for Device whitelisting?

Authenticate with SSO > IDP checks for Device fingerprint > IDP Approves Login if Device is whitelisted

In addition to the other things mentioned, some very sensitive applications in my organization must be run from a virtual desktop, which is itself must be run from a locked down corporate laptop.

We typically use VPC Endpoint Services or equivalent for enterprise customers, ie connect our private VPC with their private VPC. Pretty much the best way to do this, no VPNs to manage or IP whitelists to maintain and all traffic is local to the cloud provider.

That assumes the customers have cloud computing in use, which many do not.

That can be part of signing the contract for these tools if any thought to security was put in place

Almost all of our enterprise customers have an AWS and/or Azure cloud, and if they don’t, we’ll host on-premise as a PaaS service.

I think you’re overestimating the amount of enterprises that don’t have cloud computing.

IDP + MDM, Client certificates, VPNs, tokens/cookies, etc.

You are not a web app developer, are you?! Please say you are not! Or just doing it for fun and harmless matters.

Look at their profile. “Public sector software”. I’ll leave you to draw your own conclusions, and any relation to the topic of TFA.

Although I would agree on some days depending on my mood, if you've worked enough places you would know just as well as I do that this isn't limited to public sector software...

IP Whitelist, this is standard stuff.

IP whitelists or VPNs

With a VPN for instance

mTLS with cert in TPM.

Reply on news.ycombinator.com