向5岁的人解释“基于索赔的身份validation”

那么,不完全是一个5岁,但请尽可能避免stream行语和企业的声音。

基于声明的authentication似乎现在已经风靡一时,但我无法find一个简单实际的解释,它与现在的有什么不同(我假设“我们现在拥有”作为基于angular色的authentication),使用它的好处是什么等等。

6 Solutions collect form web for “向5岁的人解释“基于索赔的身份validation””

@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进入学校。

  1. BOY的名字是BOB。
  2. 学校名称是MONTISSORI高中
  3. class级是八年级

在他上学的第一天,当他走进学校的时候,他刷了门卡,大门打开,意味着他被称为学校的人。 这样他才是进入学校的authentication人。

到达class级后,他使用通行卡进入每class,但在第八标准门开放的第八标准class门。

在学校里,他现在正在学习八项标准,才被授权进入class级。 如果他试图进入第六个标准,那么学校的老师不会授权他。

考虑到索赔是一个告诉你一些关于用户(姓名,年龄,种族等)的属性,你使用安全令牌服务来validation这些索赔,并使用它们进行authentication之外的授权。

下面的摘录摘自维基百科( http://en.wikipedia.org/wiki/Claims-based_identity ),它是迄今为止我发现的最好的比喻

“为了更好地理解安全令牌服务的概念,可以考虑一个夜总会与门卫的类比,门卫希望防止未成年的顾客进入,为了便于这一点,他要求顾客出示驾驶执照,健康保险卡或由可信第三方(安全令牌服务)(例如省级或州级车辆牌照部门,卫生部门或保险公司)颁发的其他标识(令牌),从而减轻了夜总会确定顾客的责任只需要相信颁发机构(当然也可以自己判断所提供令牌的真实性),这两个步骤完成后,夜总会已经成功地authentication了赞助人对于他或她是法定饮酒年龄。

继续比喻,夜总会可能有一个会员系统,某些会员可能是常规会员或VIP会员。 门卫可能会要求另一个令牌,会员卡,这可能会提出另一个要求; 该会员是VIP。 在这种情况下,令牌的可信发行机构可能是俱乐部本身。 如果会员卡声称赞助人是VIP,则俱乐部可以作出相应的反应,将authentication的VIP会员申请翻译成许可,例如允许顾客坐在专属rest区,并享受免费饮料。

尽可能不具有技术性:

如果你要描述你是谁,你被允许看到或做什么,那么每一件事情都是你自称是“真实”的东西,因此这个清单上的每个“事物”都将是一个“要求”。

无论何时,当你告诉别人关于自己的某些事情,或者“声称”你被允许看到或做某事时,你就会向他们提交你的要求清单。 他们将与权威人士核实您的主张是否属实,如果是的话,他们会相信该主张的任何内容。 所以,如果你声称自己是布拉德·皮特,那么你的名单就是说你是布拉德·皮特,而且经过权威人士的确认,你的主张是真实的 – 那么他们会相信你是布拉德·皮特该列表中的其他内容。

声称 :你声称是真实的。 这可以是一条信息或您声称拥有的权限的描述。 您提出索赔的系统只需要了解索赔是什么意思,并且能够通过授权进行validation。

权威 :把你的索赔列表放在一起并签名,基本上说:“在我的权限上,这个清单中的所有内容都是真实的”。 只要阅读权利要求的系统能够与权威人员核实签名是正确的,那么索赔列表中的所有内容都将被视为真实可信。