Hacker Newsnew | past | comments | ask | show | jobs | submit | fabian2k's commentslogin

Channels are a built-in feature from Microsoft, and they do all the hard work here.

This seems to be a thin abstraction over Channels, I'd probably prefer to use Channels directly in almost all cases.

I really like Channels for in-memory queues like this, they're very nice and it's easy to make everything parallel. But if you need more than this you usually need persistence, and then you need something else entirely.


Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.

And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.

And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.


> Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities.

no, you just provide the most used ones, once you have like top 5, that helps a lot

> And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.

so just like with any other feature, really

also you should be improving docs, if they are not clear, make them clearer

it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions


>also you should be improving docs, if they are not clear, make them clearer

I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool"

There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.


The quality of the docs doesn't matter if the customer won't read them: "We'll set up a Teams meeting and you can tell us what to do"

mentioned those 10% sufficiently talented ;)

not sure about US, but here in center of europe we still have sysadmins and not many devoops people


Yeah, but in the center of Europe, customers are very price sensitive so you only target them once you've got adoption in the customers who can pay. Have to industrialize your processes before the cheap people are worth it and that takes time in startups.

Sure very smaller businesses are just cheap, but the rest want to get the most value out of that money spent. Finding and switching to alternatives with better price/performance is pretty normal I'd say.

Yeah, but the practice there is just to select on price, so I'm happy to pre-qual them out.

The necessary docs are for the SSO system. So while we can build the docs, those UIs change often and without notice, and each customer may see something different, depending on their individual config or permissions. It’s literally impossible to “just provide better docs” consistently without incurring heavy expense… thus the extra cost.

The systems are also notoriously opaque.

On the level of “I pressed the button and nothing happened.”

Fraught with bottomless wells of silent failure.

There’s inevitably a section of dumping payloads and sometimes that’s one sided.


ok, so? this is the exact BS why companies are so up the microsofts ass even though their products are mediocre, you don't have to deal with this stuff

if you want to be competitive, get your sh*t together - this is the reason why nobody wants to bother with alternatives


Not to defend this practice, but SSO does tend to produce an additional support burden. It's complex, there are many knobs to fiddle with and it can be tedious to figure out if the customer (via configuration, or their identity provider itself) or the vendor are at fault for an issue.

Just had an issue today, I'm reasonably sure it's the customer's fault. But I also misread the spec earlier and was wrong about some parts that worked out of the box with one identity provider, but not another one. So who knows. Okay, I assume this parts gets better once your SSO implementation gets older, but it's a pain when you're starting out with it.


Yep, I used to deal with this at $LastJob and amount of support burden was terrible.

Azure AD/Entra ID (Microsoft IDP) was most common and amount of IT folks who don't have a clue about it is staggering.

Companies kicking over issues to us when it's their problem. "Hey, we have a ticket saying MFA Required but account shows as Entra ID." "Send it back with contact their IT team." "Their IT team opened the ticket" rage screaming

Companies not following setup instructions. I used to provide Terraform, Powershell and Graphical setup. I can count on one hand how many people used Terraform/Powershell. This was always dicey because I got familiar with the error messages and would be "Yep, this was not setup right on their end." I had 4 phone calls with $CustomerIT swearing it was setup properly and stopped attending after that. Finally they got someone with a brain to review and finished setup.

Documentation would fall out of date because of some UI change and I'd spend a day reviewing it and updating it.


To be fair, Entra is an abysmally bad user experience; their support barely knows anything about it. Provisioning is clunky and slow. Applications are split into two halves. Self-service password reset is a half-finished joke.

Tip of the iceberg: adding a custom field to a user record is possible, but you need to use the Graph API to do it; once you've added it, it is never visible on any UI, you can only get the data back out via API. So good luck making a custom field that your clerical staff can actually work with.

There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.


>There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.

Previous customer IT support staff, is that you? I kid.

resource "azuread_service_principal_delegated_permission_grant" "grant" { service_principal_object_id = blah resource_service_principal_object_id = blah claim_values = ["openid"] }


Hmm, I could swear this didn't work the last time I tried it, but that was a while ago, and it worked an absolute treat. I was probably just confused by it. Thanks for the pointer, you've made things a tiny bit better :)

I’m confused.

_allowing_ a user to configure SSO for free doesn’t require a company to offer onboarding / education help to that user. That can be offered exclusively to paying customers.


I will say that most of the consumers of SaaS SSO solutions in our experience are the lowest bidding MSPs the customer can find or some oursourced operation. They usually employ the lowest paid fuckwits who play pass the blame around as long as possible and expect the supplier to prove every issue isn’t them.

Of course we’re happy to charge them to deal with that shit.

If we don’t then they go to twitter and the trade press to shit on our product.


i do sympathize - dealing with customers can be a nightmare sometimes.

I started a startup to fix this exact problem integrating and configuring SSO/SAML.[0]

We launched here on HN 5 years ago[1] and today power SSO for OpenAI, Cursor, Vercel, and a thousand other apps. We also found the initial configuration step to be painful for users, so we built a self-serve wizard that enables enterprise admins to fix issues.[2]

It's still crazy how much complexity there is with enterprise identity systems and managing the user lifecycle for big orgs. It's like the whole thing is made of weird edge cases and even moreso when you add SCIM, RBAC, MFA, etc etc.

(If anyone reading this also loves suffering at the intersection of IAM and developer tools, we are hiring! Email in my profile :))

[0] https://workos.com

[1] https://news.ycombinator.com/item?id=22607402

[2] https://workos.com/admin-portal


also if anyone wants to go down the rabbit hole about why SAML is hard to implement, this is a pretty interesting writeup of a major 0-day vuln we discovered earlier this year: https://workos.com/blog/samlstorm

Happy workos customer for at least 4 years. Thank you.

thank you! feedback very welcome if you have any suggestions for things to improve or ideas for what we should build next

Are you working for Stripe and the issue is names not syncing via SCIM perchance? In that case I’m the customer and reasonably sure it’s your fault ;)

No, it's far, far smaller and very specialized software.

Especially so if the customer is not a tech company or otherwise has IT staff that aren't uh motivated.

Add in SCIM and IT people "changing stuff to better align with our other stuff" and you just get a whole steamy barrel of fun.


God forbid the evil IT department just wants you to have the same username everywhere

Is there a go-to vendor/library that handles this (OIDC, SAML, SCIM) for SaaS services these days? Just like how everyone uses stripe for billing, everyone uses <vendor> for auth?

(self plug since you asked!)

WorkOS does exactly this. It's "Stripe for enterprise features."

https://workos.com

Our customers include OpenAI, Anthropic, xAI, Cursor, Perplexity, Vercel, Replit, Webflow, Clay, Hex, Carta, Plaid, Drata, Vanta, and many others. If you've used these products, you've used WorkOS!

WorkOS makes it easy to "cross the enterprise chasm." Here's a bit more of the backstory: https://x.com/grinich/status/1841569664465568248

We also launched on HN 5 years ago :) https://news.ycombinator.com/item?id=22607402


My hot take is that the SSO tax is totally legitimate because SSO is a clunky and complex feature to manage in a secure way. In fact many SSO implementations are actually not that secure because SAML is a dumpster fire when it comes to security vulnerabilities.

Most companies can get equivalent security and a better overall experience just using Google OAuth. The argument that you're having to pay for security features that should be available to everyone just doesn't compute for me if you offer Google/Microsoft OAuth, which most smaller companies are going to be using instead of Okta/etc to begin with.

If you really need SSO, it's probably because you're trying to manage massive amounts of user and do SCIM provisioning, etc. In which case, there probably will be some burden on the vendor to make sure that this all works smoothly or they'll pay a vendor (like us, I am biased as one of the Stytch founders).

We built an open source library, SAML Shield [1], to help companies secure their SAML implementations. And while hopefully this helps reduce the burden for teams maintaining in house SAML, the reality is that it definitely is a burden.

[1] https://samlshield.com/


There is no consistent ideology. There is only grift, and rage against anyone that they think wronged them.

Okay, there is ideology. But it's a bunch of different people with very different ideologies and goals.


Ah, the Soviet model of governance

Right, this is what's so amazing to me. The American conservative party spent the last 30 years taking a victory lap over the fall of the USSR, extolling the evils of socialism wherever they could, only to run in the opposite direction so hard, they ended up proving horseshoe theory by emulating everything that made the Soviets government dysfunctional.

The way I see this is in terms of attractors (in the sense of dynamics).

The dynamics are characterized mostly by institutions and rules rather than ideology.

The idea of liberalism was to get the institutions correct and so create a stable democracy.

If you destroy the institutions then the ideology behind why you did it doesn't matter. Just like it doesn't matter why you remove a load bearing wall in a building. You're at the mercy of primate emotions and everything tends toward oligarchy. That was just as true in the Soviet Union as in countless other countries throughout history.

Oligarchy is an attractor, and you need careful planning to avoid the whirlpool.


It's anything but a small language, but I wouldn't consider the stuff they're adding crap. They're useful features, but yes, this does have a price and makes the language larger.

There is value in a language with minimal syntax like Go, but it's not the only choice. C# is a pretty nice language overall, even with all the warts. But every language people actually use does have ugly stuff somewhere.


No idea what the reasons are in this specific case, but these kinds of military procurements are inherently tied to the political side.

Planes like this quickly become paperweights if you can't get replacements parts, support and ammunition. And most buyers won't be able to get significant parts of the construction into their countries. So you must trust the political stability of the country you're buying from, that they're still your friend in a decade or a few and support your planes.

Trump and his administration are anything but reliable partners.


I can't judge the legal aspects. But a significant point here is that Adblock Plus allows you do pay them to get preferential treatment for your ads.

I don't know how much this part affects the legal issues here, but for me that is quite a different situation than a pure ad blocker. There is a coercive element here, if your ad blocker is used widely enough and you take money for preferential treatment.


I would be in favor of some kind of vetting program, where you (the ad network) commit to ensuring your (customers') ads aren't scammy, e.g. advertising on software download sites with an ad that looks like a download button. Much like spam, if your ads get reported and they're verified as being in violation, you get taken off the whitelist.

Unfortunately, the main use case I have for 'ad blockers' isn't just blocking visual ads; it's blocking sometimes tens of megabytes of third-party javascript, tracking, analytics, etc., which is not just a huge privacy issue but also slows the page down tremendously.

I remember working at a company which hosted and maintained, for a client, a forum for A-level testing students in the UK, or something of the sort. Over the years, they had insisted on us adding more and more to the site; third-party widgets, trackers, analytics, etc. Each time, we pushed back because of the impact to page loads, which leads to increased bounce rate, lower time-on-site, and so on, but they were the customer and had the final say.

Then, suddenly, Google announced that it was going to start factoring page load times into pages' search ratings and, overnight, the client was frantically asking us how we could improve their page times because they were absolutely atrocious.

Fortunately, or unfortunately, a lot of techniques came around to improve page load times while still letting you load your page full of noisy cruft and garbage, so now we have pages that load nice and quick and then, over the next few seconds, ruin themselves with trash that ruins the experience. "Articles" where every paragraph break is punctuated with another ad, pages with pop-up after pop-up asking if you want to join the site, sign up for a newsletter, check out our substack.

This is the sort of reason why people gravitate towards a site's app, I suspect, but that just solves the loading time issue and prevents you from blocking trackers and ads.


> I would be in favor of some kind of vetting program, where you (the ad network) commit to ensuring your (customers') ads aren't scammy, e.g. advertising on software download sites with an ad that looks like a download button. Much like spam, if your ads get reported and they're verified as being in violation, you get taken off the whitelist.

On principle I'd disagree, and say that those types of ads should be illegal to begin with. It's amazing how many straight up scams are being advertised on otherwise trusted platforms, like Youtube. You should be responsible for what ads you put up and make sure you aren't perpetuating something illegal.

I also have no faith in the ad companies not using this as the thin end of the wedge and opportunity to start chipping away at what constitutes a non-intrusive ad. Today they only allow static ads, in two years they'll allow gifs, and in five they'll allow autoplaying audio.

If a serious bargain could be made with the ad industry that we allow them to show non-intrusive ads, and don't block them, and in exchange, they behave like human beings, then I'd take that, but I'm still not convinced the people who work in those industries are quite human to begin with. And that bargain probably wouldn't even fix the 'site loads super slow because it has to download 5 GBs of JS bloat', which is something ad blockers and the like also help to manage.


Is this a case for steel-manning? We know what this is about and what's at stake.

It's even more restrictive than than, for age verification you only get back whether the person is above the age limit or not, it's a boolean response.

So I think from that view the eID works pretty well, it provides the minimal necessary information. The bigger issue with something like this is if you use them to enforce real name policies or stuff like that.


Presumably the request contains some nonce, otherwise this is trivial to replay?

But even then, I can volunteer my ID, keep it permanently attached to a computer running a server that allows certain requests (like the boolean age check), and then provide an API / client that allows anyone anywhere to use it to pass.

No risk to me (none of my data leaks), presumably no rate limits (the card has no way to track time; at best it could store recent request timestamps but I doubt it does).

In fact even better, use stolen or lost cards. Owner will get a new one, but the old one has no way of knowing it's voided. We can build a network that is able to sign whatever info (age, gender, city, name) you want, as long as we have one ID with such info.


>But even then, I can volunteer my ID, keep it permanently attached to a computer running a server that allows certain requests (like the boolean age check), and then provide an API / client that allows anyone anywhere to use it to pass.

That’s not technical problem and it doesn’t have to be a technical solution to it. You will be committing fraud and maybe a few other crimes if underage users are involved. As soon as you will start advertising the service, you will be on law enforcement radar. Or maybe you don’t advertise it, but one of the boys using it will brag at school and get someone’s attention…


Yes and access to porn is not a technical problem. I don't see why my privacy is to be compromised because of incompetent parents.

You are not entitled to unrestricted access to any online services on condition of anonymity neither it is even possible in real world. 1) There’s always someone who knows and whom you implicitly trust. 2) trusting some random ISP or VPN provider but not IdP or specialized verification proxy is rather irrational.

It would probably be enough to stop an unsophisticated eight year old from seeing porn.

If it turns out to be a real issue, we could figure out a way to implement pairwise pseudonyms, so that each ID has a pseudonym with each service that is unlinkable to other services. If you see a million requests from a pseudonym, that pseudonym probably an ID being abused and you can block it.


You need a PIN.

That still results in the government knowing you connected to that website though.

Edit: unless there’s a blind middleman that has tight data policies?


I think it does not know. The app is open source and it just sends the Boolean. The government just gives out the id cards - they are not involved in the verification process

I know the whitelabel EU app is open source but are the derivatives going to be? As far as I understand it, every EU country will release its own version of the app.

And it's actually a good thing and not bad. EU version explicitly requests Google or Apple attestation, which at least on Android is astonishing overreach, since theres Hardware Attestation API that can confirm the platform integrity better (instead of confirming old, unpatched handsets with leaked keys are secure, LOL).

Hopefully some countries will do it the correct way.


I am talking about the German AusweisApp:

https://github.com/Governikus/AusweisApp


Not really (as far as the website and the government doesn't collaborate and share information with each other).

AFAIK the EU age verification app works by requesting bunch of digitally signed "proof of age" tokens (openid verifiable credentials) from a government institution and sends (uses up) one when you want to prove your age to a website. The website can check the validity of these tokens without connecting to the government institution.

They are even trying to do some form of blind signature or zero-knowledge proof to have better protections.

https://ageverification.dev/av-doc-technical-specification/d...

Age verification laws are easy to circumvent and they are bad for many other reason though.


...Unless the government is specifically looking out for this, that's easy to game by just submitting a bunch of requests for age validation with incrementing ages.

Is that worth it? No idea—but I'm willing to bet some surveillance advertisers think it's worth it.


I haven't read the spec so I'm not sure if you can request that or only 18+.

However doing dozens of requests requires the user's approval each time which may raise red flags and I can imagine your certificate revoked.


The hyper-polarization is already in the real world, so I don't think social media can avoid that.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: