基于角色的身份验证和基于身份的身份验证有什么区别？如果系统仅使用密码机制来验证操作员（管理员和用户的 PIN 码不同），那么据说使用“身份”或“基于角色”的身份验证？
系统提示操作员输入密码（不要求输入用户名），然后，根据输入的密码（用户或管理员）将为这两个角色提供不同的服务，或者如果密码不匹配则不提供服务。
是否可以将这种机制视为身份验证，因为 IDENTITY 只能基于 PIN 的知识进行验证？
此外，FIPS140 安全标准对第 2 级使用术语“基于角色的身份验证”，对第 3 级使用“基于身份的身份验证”（http://en.wikipedia.org/wiki/FIPS_140）。上述案例是否在 FIPS140 标准中按用途进行角色或身份认证？
基于角色的身份验证方案有哪些示例？
角色往往附加到身份，因为您不验证角色，但您验证身份。您可以授权一个身份，也可以授权一个角色。我相信这里可能会有些混乱。
角色是身份的扩展，它的工作方式通常是（例如）用户“Admin”具有“Administrator”角色。具有“管理员”角色的用户与具有“标准用户”角色的用户具有不同的权限。身份通常具有具有多个角色的能力，因此管理用户可能具有角色“管理员”和角色“标准用户”，因此具有与这两个角色相关的权限。
密码通常与身份相关联，因此您要根据身份验证密码。如果没有用户名字段，则执行密码验证的后端系统可能会查找将所有密码（或更可能只是查找密码的明文）与其关联用户进行比较。
这假设角色甚至被使用。如果没有使用任何角色，则授权只是针对身份本身；例如，如果 user == 'administrator' 允许管理事情。
“基于角色的身份验证”不是行业术语。也许您将它与基于角色的访问控制混淆了，后者是一种基于用户“角色”而不是他的身份来控制对功能的访问的方法。
例如，一个博客系统可能会定义一个“作者”角色和一个“编辑”角色。“作者”可能有权创建新故事，但无权发布它们。编辑将有权审查、修改和发布现有故事。
任何给定用户可能永久“属于”一个或多个角色，或者可能在给定会话期间被临时授予角色授权。
但至关重要的是，权限和能力永远不会直接分配给用户，而是总是分配给角色。用户通过担任给定角色间接获得该权限。同样，一个人的凭据与用户帐户相关联，而不是与角色相关联。像这样：
+-------+ +------+ +------+ +------------+
| human |===>| User |===>| Role |===>| permission |
+-------+ +------+ +------+ +------------+
您所描述的系统，其身份和访问权限仅由密码决定，不是基于角色的系统，而只是一个没有用户名的基于用户的系统。这听起来像是一个特别糟糕的主意。
我会说这里存在术语混淆。
在大多数情况下，这与其说是身份验证，不如说是授权。具体来说，您有一个场景，其中权限是基于角色的（管理员权限集与用户权限集），受质询/响应身份验证机制保护。因为验证是共享密码，所以您没有对个人进行身份验证，因此没有身份或角色成员身份的概念，至少在这个特定系统中没有实现的概念。
基于身份的身份验证绝对是一个“术语”。
这里的上下文是用于 PKI 操作的 HSM（硬件安全模块）。在基于角色的身份验证中，您有一个“密码”或智能卡等来验证角色（如加密官员、用户等）。基于身份的身份验证更进一步，并将角色分配给各个用户。例如，您可以拥有多个获得“用户”角色的个人用户。大多数基于身份的 HSM 操作还涉及 M of N 身份验证。例如，总共有 5 个用户，并且必须有 3 个用户在场才能执行操作。例如 N(5) 中的 M(3)。