Hacker News Reader

Comment by paxys | Hacker News Reader

The idea is that the company's Zoom admin should always specify the exact list of users who are allowed to be in their Zoom account. The email domain should have no bearing. So if you sign in as bob@mycorp.com, and that is a valid corporate account with the right permissions, you are let through. If you try bob+foo@mycorp.com, it should always fail. The pattern of "oh they have a mycorp.com email so they are probably legit" was broken from the start.

This is thankfully less of an issue now since everyone is moving to SAML-based logins and SCIM provisioning.

View on HN

> This is thankfully less of an issue now since everyone is moving to SAML-based logins...

Hate to break it to you but SAML is same shit different coat of paint, the xml encryption/signature/encoding stuff it pulls makes it just as much a tarpit for bugs and misconfiguration.

SCIM seems pretty decent though to explicitly state who is and isn't on the Guestlist.

What I’ve also seen is integrations with a different OIDC endpoint for company X. It’s still OIDC, but it’s not “sign in with Google”.

This will help, but at the same time will ruin the whole idea of seamless corp users registration in external service, and damage adoption and increase friction.

If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.

Most companies have these directories but in different forms, including Wiki pages. The idea of auto-enrollment is that it is based on a standard and widely adopted OAuth protocol.

They sure have those directories in different forms out of sheer need but every time I’ve seen people have to consult wiki pages to get information that should be in a standardized directory it’s a shitshow that is borderline impossible to automate.

Employee records as wiki pages? That must be a joke, right?

Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.

Why not on a piece of paper then?..

It's hard to share and update.

Because it’s not suitable for machine-processing of employee data. This belongs in a database, Active Directory, or HR software. Do you also do payroll with wiki pages?

Not everything should be suitable for machine-processing. A certified MS professional should administer Active Directory. HR software should be paid for and learned how to use it first.

On my second startup we payrolled via Google Spreadsheet. By the way, it is also an okay storage for employee data.

I suppose I'll confess that you are correct, this approach is totally viable at smaller scales. I've just seen what happens in a large business context.

It's above all, a security nightmare, since the wiki pages are perpetually out of date and incomplete, and it makes the process of thing like provisioning and deprovisioning access so labor intensive.

Reply on news.ycombinator.com