4 ms·

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 hav

by paxys 3y ago

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.

klodolph 3y ago
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”.
SergeAx 3y ago
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.
- layer8 3y ago
  If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.
  - SergeAx 3y ago
    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.
    - faeriechangling 3y ago
      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.
    - layer8 3y ago
      Employee records as wiki pages? That must be a joke, right?
      - SergeAx 3y ago
        Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.
        IlliOnato 3y ago
        Why not on a piece of paper then?..
        SergeAx 3y ago
        It's hard to share and update.
        layer8 3y ago
        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?
        SergeAx 3y ago
        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.
        faeriechangling 3y ago
        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.
tehbeard 3y ago
> 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.

by paxys 3y ago

klodolph 3y ago

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”.

SergeAx 3y ago

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.

layer8 3y ago
If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.
- SergeAx 3y ago
  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.
  - faeriechangling 3y ago
    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.
  - layer8 3y ago
    Employee records as wiki pages? That must be a joke, right?
    - SergeAx 3y ago
      Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.
      - IlliOnato 3y ago
        Why not on a piece of paper then?..
        SergeAx 3y ago
        It's hard to share and update.
      - layer8 3y ago
        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?
        SergeAx 3y ago
        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.
        faeriechangling 3y ago
        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.

tehbeard 3y ago

> 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.