我为一个大型组织工作（数千名员工 + 可能有数以万计的外部用户可以部分访问部分内部信息），其中许多人使用用户名/密码（定期过期）进行身份验证。
但是，这些人中的大多数（对于员工而言，无论他们通常在 Windows、Linux 还是 iOS 上工作，都可以确定）都提供了一个 Active Directory 帐户（内部电子邮件地址），并且 AFAIK 我们所有的系统都允许使用ADFS / Active登录目录/LDAP 身份提供者。
即使对于那些访问权限非常有限的外部用户（例如对于某些报告），如果不允许 ADFS，我们也可以使用主要身份提供者（例如Google 身份提供者）实施解决方案。
拥有用户名/密码会给用户带来负担，许多人使用 Excel 文件和电子邮件来存储它们，这会带来安全风险。另外，我听说过用户共享，所以不可能知道谁实际使用了某个用户。
因此，通过仅使用 Windows 凭据以及可能使用其他身份提供者，用户在处理公司的所有系统时只需注意一对凭据。此外，凭据共享将消失。
问题：在大型组织中使用专用用户/密码而不是身份提供者是否有任何客观原因？
对于大多数组织来说，一个全面的统一身份系统是一件好事。你问是否有任何理由不这样做。我将列出一些在不同组织中可能有效或无效的内容：
系统不支持身份提供者。您可能有一个旧的基于终端的大型机系统，它不容易链接到 AD。有许多商业产品可以将遗留产品与身份系统联系起来，尽管这些产品的成本可能很高。或者，您可能拥有难以与之集成的基于云的系统（如 Salesforce）。
该系统是敏感的，您不想在身份系统遭到破坏的情况下暴露它。这可能对少数高度敏感的系统有效，尽管这个论点在企业环境中被过度使用。如果您的身份提供者是 AD，则违反 AD 可能意味着违反人们将用来管理这些系统的所有工作站，因此分离只不过是安全剧院。
无法从系统访问身份提供者。一个常见的例子是 DMZ 中的面向 Internet 的系统被防火墙阻止访问内部 AD。我见过大型组织为 DMZ 系统创建单独的 AD。开发与生产系统可能会出现类似的问题。
一些用户不是身份提供者的一部分。经典示例是您有几个外部用户访问内部系统。您可以通过让系统支持多种身份验证方法或允许外部用户在您的身份提供者中进行处理，但有适当的限制。
将系统与身份提供者集成的困难是否值得收益是一种平衡行为。大多数 IT 管理员接受管理大量凭据是工作的一部分。
首先，Active Directory 是一种专有协议，在 Windows 世界之外使用起来可能不是最简单的。出于这个原因，通常至少有 2 种身份验证，一种用于 Windows 世界，另一种用于其他系统（通常是 Unix/Linux）。这对于用户来说几乎是透明的，只要其中一个身份验证提供程序在另一个上同步。
这通常可以解决大部分身份验证需求。仍然可以保留的是：
这适用于可接受的用例。但还有另一类：建立 SSO 系统需要时间和金钱方面的成本。一些组织可能选择不去那里，因为他们认为不值得，或者有时因为他们没有意识到可能的收益。只有在后一种用例中，您可以建议您的直接经理这会非常有趣，但您必须找到真正的用例，这样可以节省时间或防止错误。每个人都这样做可能不足以说服大老板......
这是对 ADFS 的打击，因为它依赖于 AD，这需要一些努力才能正确保护。
如果您完全使用 Active Directory——尤其是当它控制对关键系统的访问时——您需要设计您的环境以解决其严重的安全缺陷。
至少，您应该根据其分层管理模型实施 Microsoft 的红色森林设计，以减轻散列传递 (PtH)、票证传递 (PtT) 和金票攻击。
在与外部用户打交道时，ADFS 远远优于在您的域中创建帐户或建立 AD 信任。如果您可以使用 ADFS，请务必这样做。
由于您特别提到了 Google Identity，它们基于 OAUTH，并且OAUTH 应该与 ADFS 互操作。
由于 ADFS 只是 Microsoft 对 SAML 身份提供程序的实现，因此随着时间的推移它应该会变得更加有用。在企业方面，SAML 仍然相当新，但它一直在增长。
管理用户仍然需要多个帐户。你无法合理地消除这种需求。任何可以访问 Internet 的帐户都不应拥有管理基础设施或在开发/测试环境中进行更改的特权访问权限。
即使管理员必须拥有 2-3 个单独的 AD 帐户，您仍然可以进行整合。例如，Oracle 和 MS SQL 都支持使用 Windows 凭据进行身份验证，因此您的 DBA 和开发人员将不再需要每个实例中的唯一用户/通行证帐户。
我要提出的一个问题是无法访问身份管理系统的实时攻击。例如，如果有人正在攻击您的身份管理服务器并成功进入，您可以在知道后立即采取行动。如果有人损害了第 3 方身份提供者，您可能在几个月内不知道他们何时/是否决定披露违规行为。