向 5 岁的孩子解释“基于声明的身份验证”

@Marnix 有一个很好的答案，但要远离它的技术方面：

基于声明的身份验证是关于定义您信任的人，以便为您提供有关身份的准确信息，并且只使用所提供的信息。我的（）首选示例是在酒吧。想象一下，您想在酒吧喝杯啤酒。理论上，调酒师应该要求您提供年龄证明。你怎么证明？好吧，一种选择是让调酒师把你切成两半，然后数一数戒指的数量，但这可能会有一些问题。另一种选择是让您在一张纸上写下您的生日，酒保同意或不同意。第三种选择是去政府，拿到身份证，然后把身份证出示给酒保。

有些人可能会嘲笑只在一张纸上写下你的生日的想法，但当你在应用程序本身内验证用户时就会发生这种情况，因为这取决于调酒师（或你的应用程序）来信任这张纸.但是，我们相信政府的说法，即身份证上的生日是有效的，身份证是给请求喝酒的人的。出于所有意图和目的，调酒师（或应用程序）并不真正关心身份验证是如何发生的，因为信任。除了您的出生日期，调酒师对您一无所知，因为这就是调酒师需要知道的全部内容。现在，调酒师可以存储他们认为对他们很重要的信息，例如您最喜欢的饮料，但政府不在乎（因为它不是权威来源），所以调酒师以自己的方式存储这些信息。

CBA的关键是“谁是身份的权威来源？”

---

（这是我个人对此的看法，其他人可能会有所不同。请发表其他观点作为单独的答案。）

基于声明的身份/身份验证/授权是通过将身份验证/授权转换为单独的 (Web) 服务来将用户授权的维护和用户登录从 (Web) 应用程序中分离出来。

例如，当我第一次浏览启用声明的 Web 应用程序时，它会将我的浏览器重定向到它信任的“登录服务”。我将对该服务进行身份验证（使用 Windows 身份验证、智能卡或其他），作为响应，它会发回一个“令牌”，浏览器会将其发回给 Web 应用程序。现在，Web 应用程序检查令牌是否由其受信任的登录服务进行数字签名，然后查看令牌中的“声明”。纯粹基于这些声明，应用程序决定为用户提供什么功能。

声明几乎总是包含用户的身份，通常还有与授权相关的声明（“此用户可以查看销售数据，但不能更新”），有时还包括其他信息（“鞋码 = 42”）。

关键是应用程序不知道也不关心用户是如何被认证的，也不关心授权是如何管理的：它只使用来自签名令牌中声明的信息来确定用户是谁和/或用户可以做什么查看或执行和/或有关用户的任何其他信息。

（是的，我假设这里是一个非常聪明和消息灵通的 5 岁孩子。:-)

---

以下真实世界示例取自 A Guide to Claims-Based Identity and Access Control (2nd Edition)。

一个非常熟悉的类比是您每次访问机场时遵循的身份验证协议。您不能简单地走到门口并出示您的护照或驾驶执照。相反，您必须先在售票处办理登机手续。在这里，您提供任何有意义的凭证。如果你出国，你需要出示你的护照。对于国内航班，您需要出示您的驾驶执照。在验证您的照片 ID 与您的面部匹配后（身份验证），代理会查找您的航班并验证您是否已支付机票费用（授权）。假设一切正常，您会收到一张登机牌，然后带到登机口。登机牌信息量很大。登机口代理知道您的姓名和飞行常客号码（身份验证和个性化）、您的航班号和座位优先级（授权），甚至更多。登机口代理拥有高效完成工作所需的一切。登机牌上也有特殊信息。它被编码在条形码和/或背面的磁条中。此信息（例如登机序列号）证明该通行证是由航空公司签发的，不是伪造的。从本质上讲，登机牌是航空公司对您提出的一组签名声明。它规定您可以在特定时间登上特定航班并坐在特定座位上。当然，代理不需要对此深思熟虑。他们只需验证您的登机牌，阅读上面的声明，然后让您登机。同样重要的是要注意，获取已签名的声明集的方法可能不止一种，即您的登机牌。您可以前往机场的售票柜台，也可以使用航空公司的网站在家中打印登机牌。登机的登机口工作人员并不关心登机牌是如何创建的。他们不在乎您使用的是哪个发行商，只要它受到航空公司的信任。他们只关心这是一组真实的声明，允许您上飞机。在软件中，这组声明称为安全令牌。每个安全令牌都由创建它的发行者签名。如果用户提供来自受信任颁发者的有效签名安全令牌，则基于声明的应用程序认为用户已通过身份验证。

---

对于一个 5 岁的男孩，让他假设他通过父母签署的申请表加入了新学校。在学校管理层批准他的申请后，他会得到一张门禁卡，其中包含以下所有信息，我们可以称之为 CLAIMS 进入学校。

男孩的名字是鲍勃。学校名称是蒙蒂索里高中班是 8 年级

上学第一天，当他走进学校时，他刷了他的门禁卡，大门打开了，这意味着他已经被声称是学校的一员。通过这种方式，他是一个认证的人进入学校。

到达他的班级后，他使用门禁卡进入每个班级，但在 8th Standard Class 门打开了，因为他声称来自 8th Standard。

在学校，他只被授权进入他的班级，因为他现在正在学习 8th Standard。如果他尝试进入第六标准，学校老师不会授权他。

---

尽可能非技术性：

如果你要描述关于你是谁以及你被允许看到或做什么的任何事情，那么这些事情中的每一个都将是你“声称”为真实的事情，因此该列表中的每个“事情”都将是“宣称”。

每当你告诉某人一些关于你自己的事情或“声称”你被允许看到或做某事时，你都会把你的声明清单交给他们。他们将与权威机构核实您的声明是否属实，如果属实，他们将相信该声明清单上的任何内容。因此，如果您声称自己是布拉德皮特，您的声明清单显示您是布拉德皮特，并且经过权威机构验证，您的声明都是真实的——那么他们会认为您是布拉德皮特以及该列表中的其他任何内容。

声称：你声称是真实的。这可以是一条信息或您声称拥有的权限的描述。您向其提出索赔的系统只需要了解索赔是/意味着什么，并且还能够与当局核实。

权威：将您的声明列表放在一起并签名的系统，基本上说“根据我的授权，此列表中的所有内容都是真实的”。只要读取声明的系统可以通过权威验证签名是正确的，那么声明列表中的所有内容都将被认为是真实的。

此外，我们不要将其称为“基于声明的身份验证”，而是将其称为“基于声明的身份”。

技术性稍强：

因此，现在在此过程中，您使用某种机制（用户名/密码、客户端密码、证书等）进行身份验证，并为您提供一个令牌，证明您就是您所说的那个人。然后，您将该访问令牌换成 ID 令牌。该过程将使用您的身份来查找和构建声明列表，对其进行签名，然后将包含您所有声明的 ID 令牌交还给您。

作为授权步骤，根据其实施方式，资源将查看您的 ID 令牌（声明），然后检查您是否具有访问该资源所需的声明。

因此，例如，如果资源“CastleBlack/CommandersTower”说“你必须有权访问黑色城堡并成为领主指挥官，那么它将查看你的声明列表，看看这两件事是否属实。

如您所见，“声明”可以是任何东西。它可以是一个角色，它可以是一个事实，它可以是一面旗帜。它只是一个键值对列表，“值”是可选的。有时只是看看索赔是否存在：

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

因此，如果 Jon 登录并尝试访问上述资源，他将被拒绝，因为虽然他是他所说的那个人并且他确实可以访问城堡黑色，但他不再是指挥官，也没有明确的访问权限统帅塔，因此不能隐式进入统帅之塔。

更具体地说，“CastleBlack”可能是一个[更大的]范围，每个区域都有一个特定的权限，但这是一个不同的讨论。

每个应用程序处理访问的方式将有所不同，但它将使用声明来完成。

---

考虑到声明是一个属性，它告诉您有关用户的一些信息（姓名、年龄、种族等），您使用安全令牌服务来验证这些声明，并将它们用于身份验证之外的授权。

以下摘录摘自 Wikipedia (http://en.wikipedia.org/wiki/Claims-based_identity)，这是我迄今为止找到的最好的类比

“为了更好地理解安全令牌服务的概念，可以考虑将夜总会与门卫进行类比。门卫想要阻止未成年顾客进入。为此，他要求顾客出示驾驶执照、健康保险卡或由省或州车辆执照部门、卫生部门或保险公司等受信任的第三方（安全令牌服务）颁发的其他身份证明（令牌）。因此减轻了夜总会确定顾客身份的责任年龄。它只需要信任发行机构（当然还要自己判断所提供的代币的真实性）。完成这两个步骤后，夜总会就成功地验证了顾客的身份。法定饮酒年龄。

继续打个比方，夜店可能有会员制，某些会员可能是普通会员，也可能是VIP。门卫可能会要求另一个象征物，即会员卡，这可能会提出另一个要求；该会员是VIP。在这种情况下，代币的可信发行机构可能是俱乐部本身。如果会员卡声称顾客是 VIP，那么俱乐部可以做出相应的反应，将经过验证的 VIP 会员资格声明转化为许可，例如允许顾客坐在专属休息区并获得免费饮料。”

---