向5岁的人解释“基于索赔的身份validation”
那么，不完全是一个5岁，但请尽可能避免stream行语和企业的声音。
基于声明的authentication似乎现在已经风靡一时，但我无法find一个简单实际的解释，它与现在的有什么不同（我假设“我们现在拥有”作为基于angular色的authentication），使用它的好处是什么等等。
@Marnix有一个相当不错的答案，但要摆脱它的技术方面：
基于声明的身份validation是关于定义您信任的人，为您提供关于身份的准确信息，并且只使用所提供的信息。 我的（去）例子是在一个酒吧。 想象一下，你想在酒吧喝啤酒。 理论上酒保应该要求你提供年龄certificate。 你如何certificate它？ 那么，一个select是让酒保把你减半，并计数戒指的数量，但可能会有一些问题。 另一种select是让你在一张纸上记下你的生日，酒保批准或不批准。 第三个select是去政府，拿到身份证，然后把身份证交给调酒师。
有些人可能会嘲笑在一张纸上写下你生日的想法，但是当你在应用程序本身中对用户进行authentication时会发生这种情况，因为由酒保（或者你的应用程序）来信任这张纸。 不过，我们相信政府的说法是，身份证上的生日是有效的，身份证是要求喝酒的人。 对于所有的意图和目的，酒保（或应用程序）并不真正关心authentication是如何发生的，因为信任。 除了你的出生date之外，酒保对你一无所知，因为这是调酒师需要知道的。 现在，调酒师可以存储他们认为对他们很重要的信息，比如你喜欢的饮料，但是政府并不关心（因为它不是权威的来源），所以调酒师以自己的方式存储这些信息。
CBA的关键是“谁是身份的权威来源？”
（这是我个人对此的看法，其他人可能有所不同，请将其他观点作为单独的答案发表）
通过将authentication/授权转变为单独的（networking）服务，基于声明的身份/authentication/授权是将用户授权的维护和用户login分离出（networking）应用程序。
因此，例如，当我第一次浏览到启用了声明的Web应用程序时，它会将我的浏览器redirect到它所信任的“login服务”。 我将对该服务进行身份validation（使用Windows身份validation，智能卡或其他任何方式），并作为响应返回浏览器发送回Web应用程序的“令牌”。 现在，Web应用程序检查令牌是否由其受信任的login服务进行数字签名，然后查看令牌中的“声明”。 纯粹基于这些声明，应用程序决定用户提供什么function。
索赔将几乎总是包括用户的身份，通常也有授权相关的索赔（“这个用户可能查看销售数据，但不更新”），有时还有其他信息（'鞋子大小= 42'）。
关键在于应用程序不知道用户如何进行身份validation，也不知道如何pipe理授权：它只使用来自签名令牌中的声明的信息来确定用户是谁和/或用户可以看到或做和/或关于用户的任何其他信息。
（是的，我假设一个非常聪明，消息灵通的5岁小孩。:-)
下面的真实世界的例子是从基于索赔的身份和访问控制指南（第二版） 。
一个非常熟悉的比喻是您每次访问机场时遵循的身份validation协议。 你不能简单地走到门口，出示你的护照或驾驶执照。 相反，你必须先在售票柜台办理登机手续。 在这里，你提出任何凭证是有道理的。 如果你要出国，你可以出示护照。 国内航class，请出示驾驶执照。 validation您的照片ID与您的面孔（ 身份validation ）相匹配后，代理会查找您的航class，并validation您是否已付款（ 授权 ）。 假设一切顺利，您将收到一张登机牌，然后登机。
登机牌非常丰富。 门票代理了解您的姓名和常旅客号码（身份validation和个性化），您的航class号和座位优先权（授权），甚至更多。 门卫们有他们需要的一切来有效地完成他们的工作。
登机牌也有特殊的信息。 它被编码在条形码和/或背面的磁条上。 这个信息（例如登机编号）certificate通行证是由航空公司发行的，不是伪造的。
从本质上说， 登机牌是由航空公司对你所做的一系列签名 。 它规定你可以在特定的时间登机，坐在特定的座位上。 当然，代理商不需要对此有深入的思考。 他们只是validation你的登机证，阅读它的要求，让你登机。
同样重要的是要注意，可能有不止一种方式来获得已签署的登机牌索赔。 您可以去机场售票处，也可以使用航空公司的网站，并在家打印登机牌。 登机的门票代理不在乎登机牌是如何build立的; 他们不关心你使用哪个发行人，只要它是航空公司信任的。 他们只关心这是一个真实的声称，允许你上飞机。
在软件中， 这一组索赔被称为安全令牌 。 每个安全令牌由创build它的发行者签署 。 基于声明的应用程序认为，如果用户从受信任的颁发者提供了有效的，签名的安全令牌，则authentication用户 。
对于一个五年的男孩，请他假设他通过父母签署申请来join一所新学校。 经学校pipe理部门批准申请后，他会得到一张存取卡，里面包含以下所有的信息，我们可以把它称为CLAIMS进入学校。
- BOY的名字是BOB。
- 学校名称是MONTISSORI高中
- class级是八年级
在他上学的第一天，当他走进学校的时候，他刷了门卡，大门打开，意味着他被称为学校的人。 这样他才是进入学校的authentication人。
到达class级后，他使用通行卡进入每class，但在第八标准门开放的第八标准class门。
在学校里，他现在正在学习八项标准，才被授权进入class级。 如果他试图进入第六个标准，那么学校的老师不会授权他。
考虑到索赔是一个告诉你一些关于用户（姓名，年龄，种族等）的属性，你使用安全令牌服务来validation这些索赔，并使用它们进行authentication之外的授权。
下面的摘录摘自维基百科（ http://en.wikipedia.org/wiki/Claims-based_identity ），它是迄今为止我发现的最好的比喻
“为了更好地理解安全令牌服务的概念，可以考虑一个夜总会与门卫的类比，门卫希望防止未成年的顾客进入，为了便于这一点，他要求顾客出示驾驶执照，健康保险卡或由可信第三方（安全令牌服务）（例如省级或州级车辆牌照部门，卫生部门或保险公司）颁发的其他标识（令牌），从而减轻了夜总会确定顾客的责任只需要相信颁发机构（当然也可以自己判断所提供令牌的真实性），这两个步骤完成后，夜总会已经成功地authentication了赞助人对于他或她是法定饮酒年龄。
继续比喻，夜总会可能有一个会员系统，某些会员可能是常规会员或VIP会员。 门卫可能会要求另一个令牌，会员卡，这可能会提出另一个要求; 该会员是VIP。 在这种情况下，令牌的可信发行机构可能是俱乐部本身。 如果会员卡声称赞助人是VIP，则俱乐部可以作出相应的反应，将authentication的VIP会员申请翻译成许可，例如允许顾客坐在专属rest区，并享受免费饮料。
尽可能不具有技术性：
如果你要描述你是谁，你被允许看到或做什么，那么每一件事情都是你自称是“真实”的东西，因此这个清单上的每个“事物”都将是一个“要求”。
无论何时，当你告诉别人关于自己的某些事情，或者“声称”你被允许看到或做某事时，你就会向他们提交你的要求清单。 他们将与权威人士核实您的主张是否属实，如果是的话，他们会相信该主张的任何内容。 所以，如果你声称自己是布拉德·皮特，那么你的名单就是说你是布拉德·皮特，而且经过权威人士的确认，你的主张是真实的 – 那么他们会相信你是布拉德·皮特该列表中的其他内容。
声称 ：你声称是真实的。 这可以是一条信息或您声称拥有的权限的描述。 您提出索赔的系统只需要了解索赔是什么意思，并且能够通过授权进行validation。
权威 ：把你的索赔列表放在一起并签名，基本上说：“在我的权限上，这个清单中的所有内容都是真实的”。 只要阅读权利要求的系统能够与权威人员核实签名是正确的，那么索赔列表中的所有内容都将被视为真实可信。
