解释“基于声明的认证”给一个5岁的孩子
嗯，不完全是针对 5 岁的孩子，但请尽可能避免使用流行语和企业用语。
基于声明的身份验证现在似乎很流行，但我找不到简单实用的解释来说明它实际上是什么，它与我们现在拥有的有何不同（我假设“我们现在拥有的”）基于角色的身份验证），使用它的好处是什么，等等。
Well, not exactly to a 5-year-old, but please avoid buzzword and enterprisespeak if possible.
Claims-based authentication seems to be all the rage now, but I could not find a simple and down-to-earth explanation of what it actually is, how is it different from what we have now (I assume "what we have now" to be role-based authentication), what are the benefits of using it, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
@Marnix 有一个很好的答案，但远离它的技术方面：
基于声明的身份验证是关于定义您信任的谁可以为您提供有关身份的准确信息，并且仅使用所提供的信息。我的首选例子是在酒吧。想象一下您想在酒吧喝杯啤酒。理论上，调酒师应该要求您提供年龄证明。你如何证明这一点？好吧，一种选择是让调酒师把你切成两半并数一下戒指的数量，但这可能会出现一些问题。另一种选择是您在一张纸上写下您的生日，调酒师同意或不同意。第三种选择是去政府，拿到身份证，然后将身份证出示给调酒师。
有些人可能会嘲笑在一张纸上写下您的生日的想法，但这就是您在应用程序本身中验证用户身份时发生的情况，因为调酒师（或您的应用程序）是否信任这张纸取决于调酒师（或您的应用程序） 。不过，我们相信政府的说法，即身份证上的生日是有效的，并且该身份证是为要求饮料的人准备的。出于所有意图和目的，调酒师（或应用程序）并不真正关心由于信任而进行的身份验证。除了您的出生日期之外，调酒师对您一无所知，因为这是调酒师需要知道的全部内容。现在，调酒师可以存储他们认为对他们重要的信息，例如您最喜欢的饮料，但政府不在乎（因为它不是权威来源），因此调酒师以自己的方式存储这些信息。
CBA的关键在于“身份的权威来源是谁？”
@Marnix has a pretty good answer, but to step away from the technical aspect of it:
Claims Based Authentication is about defining who you trust to give you accurate information about identity, and only ever using that information provided. My (the) go-to example is at a bar. Imagine for a moment that you want to get a beer at the bar. In theory the bartender should ask you for proof of age. How do you prove it? Well, one option is to have the bartender cut you in half and count the number of rings, but there could be some problems with that. The other option is for you to write down your birthday on a piece of paper to which the bartender approves or disapproves. The third option is to go to the government, get an ID card, and then present the ID to the bartender.
Some may laugh at the idea of just writing your birthday on a piece of paper, but this is what is happening when you are authenticating users within the application itself because it is up to the bartender (or your application) to trust the piece of paper. However, we trust the government's assertion that the birthday on the ID is valid, and the ID is for the person requesting the drink. For all intents and purposes, the bartender (or application) doesn't really care how the authentication occurred because of the trust. The bartender knows nothing about you except your date of birth because that's all the bartender needs to know. Now, the bartender could store information that they think is important to them, like your favorite drink, but the government doesn't care (as it isn't the authoritative source), so the bartender stores that information in his own way.
The key to CBA is "who is the authoritative source of the identity?"
（这是我个人的看法，其他人可能会有所不同。请发布其他观点作为单独的答案。）
基于声明的身份/身份验证/授权是将用户授权的维护和用户登录的维护分开通过将身份验证/授权转变为单独的（Web）服务，脱离（Web）应用程序。
例如，当我第一次浏览启用声明的 Web 应用程序时，它会将我的浏览器重定向到它信任的“登录服务”。我将对该服务进行身份验证（使用 Windows 身份验证、智能卡或其他方式），并作为响应发送回一个“令牌”，浏览器将其发送回 Web 应用程序。现在，Web 应用程序检查令牌是否由其可信登录服务进行数字签名，然后查看令牌中的“声明”。纯粹基于这些声明，应用程序决定向用户提供哪些功能。
这些声明几乎总是包含用户的身份，通常还有与授权相关的声明（“该用户可以查看销售数据，但不能更新它”），有时还包括其他信息（“鞋码 = 42”）。
关键点是应用程序不知道也不关心用户是如何进行身份验证的，也不关心如何管理授权：它只使用签名令牌中声明中的信息来确定用户是谁和/或用户可以做什么查看或执行操作和/或有关用户的任何其他信息。
（是的，我假设这里有一个非常聪明且消息灵通的 5 岁孩子。:-)
(This is my personal take on this, others may differ. Please post other viewpoints as separate answers.)
Claims-based identity/authentication/authorization is about separating the maintenance of user authorizations and user sign-in out of a (web) application, by turning authentication/authorization into a separate (web) service.
So for example, when I browse to a claims-enabled web application for the first time, it will redirect my browser to a 'logon service' which it trusts. I will authenticate to that service (using Windows authentication, a smart card, or whatever), and in response it sends back a 'token', which the browser sends back to the web application. Now the web application checks that the token is digitally signed by its trusted logon service, and then looks at the 'claims' in the token. Based purely on those claims, the application decides what functionality the user is offered.
The claims will almost always include the user's identity, often there are also authorization-related claims ('this user may view Sales data, but not update it'), and sometimes other information as well ('shoe size = 42').
The key point is that the application does not know nor care how the user was authenticated, nor how the authorizations are administrated: it only uses the information from the claims in the signed token to determine who the user is and/or what the user may see or do and/or any other information about the user.
(Yes, I'm assuming a pretty intelligent and well-informed 5-year-old here. :-)
以下实际示例取自基于声明的身份和访问控制指南 (第二版）。
The following real world example is taken from A Guide to Claims-Based Identity and Access Control (2nd Edition).
对于一个 5 岁的男孩，让他假设他通过父母签署的申请表加入了一所新学校。在学校管理层批准他的申请后，他会获得一张门禁卡，其中包含以下所有信息，我们可以将其称为进入学校的“索赔”。
开学第一天，当他走进学校时，他刷了门禁卡，大门打开了，这意味着他被认为是学校的人之一。这样，他就是一个可以进入学校的认证人员。
到达自己的班级后，他使用门禁卡进入各个班级，但在第8标准班时门打开了，因为他声称自己来自第8标准班。
在学校里，他只被授权进入他的班级，因为他现在正在学习第八标准。如果他尝试进入第六标准，学校老师不会授权他。
For a 5 years boy, ask him to assume he joined a new school by signing the application by his parents. After approval from school management for his application, he gets a access card which contains all the below information which we can call it CLAIMS to enter into the school.
On first day of his school while he walks into the school, he swiped his access card and the gates opened, means he has been CLAIMED AS one of the person from the school. In this way he is an AUTHENTICATED PERSON to enter into the school.
After reaching to his class, he used access card to enter into each class, but at 8th Standard Class doors opened as he Claimed to be from 8th Standard.
In the school, he is only AUTHORIZED to enter into his class as he is now studying 8th Standard. And if he try to enter into 6th Standard, the school teacher WON'T AUTHORIZE him.
尽可能非技术性：
如果你要描述任何关于你是谁以及你被允许看到或做的事情，那么每一件事情都将是你“声称”真实的事情，因此每件“事情”该清单上将有一个“索赔”。
每当你告诉某人一些关于你自己的事情或“声称”你被允许看到或做某事时，你就向他们提供了你的声明清单。他们将向权威机构核实您的说法是否属实，如果属实，他们就会相信该声明清单上的任何内容。因此，如果您声称自己是布拉德·皮特，那么您的声明列表表明您是布拉德·皮特，并且经过权威机构验证您的声明都是真实的 - 那么他们就会相信您是布拉德·皮特该列表中的任何其他内容。
声明：您声明的内容是真实的。这可以是一条信息或您声称拥有的权限的描述。您提出索赔的系统只需要了解索赔是什么/意味着什么，并且还能够向当局进行验证。
权威：将您的声明列表放在一起并签名的系统，基本上表示“根据我的授权，此列表中的所有内容都是真实的”。只要读取声明的系统能够向权威机构验证签名是否正确，那么声明列表中的所有内容都将被认为是真实的。
另外，我们不要将其称为“基于声明的身份验证”，而是将其称为“基于声明的身份”。
稍微技术性一点：
因此，现在在此过程中，您使用某种机制（用户名/密码、客户端密钥、证书等）进行身份验证，这会为您提供一个令牌这证明你就是你所说的那个人。然后，您将该访问令牌换成 ID 令牌。该过程将使用您的身份来查找并构建声明列表，对其进行签名，然后将包含您所有声明的 ID 令牌返还给您。
作为授权步骤，根据其实施方式，资源将查看您的 ID 令牌（声明），然后检查您是否拥有访问该资源所需的声明。
例如，如果资源“CastleBlack/CommandersTower”说“您必须有权访问黑城堡并成为总司令，那么它将查看您的声明列表，看看这两件事是否属实。
当您看，“声明”可以是任何东西。它可以是一个角色，可以是一个事实，它可以是一个标志，它只是一个键值对列表，而“值”有时只是看看是否。索赔存在：
因此，如果乔恩登录并尝试访问上述资源，他将被拒绝，因为虽然他是他所说的那个人，并且他确实可以访问黑城堡，但他不再是领主指挥官，也没有明确的访问权限指挥官的塔，因此不能隐式进入主指挥官的塔。
更具体地说，“CastleBlack”可能是一个[更大的]范围，每个区域都有一个特定的权限，但这是
每个应用程序如何处理访问的不同 讨论。将会有所不同，但它会使用声明来做到这一点。
As non-technical as possible:
If you were to describe anything about who you are and what you were allowed to see or do, each of those things would be something that you were "claiming" to be true, and thus each "thing" on that list would be a "claim".
Anytime you tell someone something about yourself or "claim" that you're allowed to see or do something, you hand them your list of claims. They will verify with an authority that your claims are true and if they are, they'll believe anything on that list of claims. So if you claim that you're Brad Pitt, your list of claims says that you're Brad Pitt, and it was verified with the authority that your claims are all true -- then they will believe that you're Brad Pitt along with anything else in that list.
Claim: what you claim to be true. This can be a piece of information or a description of a permission you're claiming to have. The system to which you present your claims only need to understand what the claim is/means and also be able to verify with the authority.
Authority: The system that puts your list of claims together and signs it which basically says "On my authority, everything in this list is true." So long as the system reading the claims can verify with the authority that the signature is correct, then everything in the list of claims will be considered authentic and true.
Also, let's not call it "claims based authentication", instead let's call it "claims based identity".
Slightly more technical:
So now in this process, you authenticate using some sort of mechanism (username/password, client secret, certificate, etc.) and that gives you a token that proves you are who you say you are. Then, you trade that access token for an ID token. That process will use your identity to find and build a list of claims, sign it and then hand you back an ID token that has all of your claims.
As the authorization step, depending on how it is implemented, the resource will look at your ID token (claims) and then check if you have the necessary claims to access that resource.
So for example, if the resource "CastleBlack/CommandersTower" says that "you have to have access to castle black and be lord commander, then it's going to look at your list of claims to see if both of those things are true.
As you see, "claims" can be anything. It can be a role, it can be a fact, it can be a flag. It's just a list of key-value pairs and the "value" is optional. Sometimes it's just about seeing if the claim exists:
So if Jon logged in and tries to access the resource described above, he would be denied because, while he is who he says he is and he does have access to castle black, he is no longer lord commander nor does he have explicit access to the commander's tower, and thus cannot implicitly enter the lord commander's tower.
More specifically, "CastleBlack" would probably be a [larger] scope, and each area would be a specific permission, but that's a different discussion.
How each application deals with access is going to be different, but it will use claims to do it.
考虑到声明是一个属性，可以告诉您有关用户的一些信息（姓名、年龄、种族等），您可以使用安全令牌服务来验证这些声明，并将它们用于除身份验证之外的授权。
以下摘录自维基百科 (http://en.wikipedia.org/wiki/Claims-based_identity ），这是我迄今为止发现的最好的类比
“为了更好地理解安全令牌服务的概念，请考虑夜总会与门卫的类比。门卫希望防止未成年顾客为了方便这一点，他要求顾客出示驾驶执照、健康保险卡或由受信任的第三方（安全令牌服务）（例如省或州车辆执照部门）颁发的其他身份证明（令牌），因此，夜总会无需承担确定顾客年龄的责任（当然，完成这两个步骤后，它还可以自行判断所提供的令牌的真实性）。夜总会已成功验证顾客的身份声称他或她已达到法定饮酒年龄。
继续类比，夜总会可能有会员制度，某些会员可能是普通会员，也可能是VIP会员。门卫可能会要求提供另一个令牌，即会员卡，这可能会提出另一项要求；该会员是 VIP。在这种情况下，代币的可信发行机构可能是俱乐部本身。如果会员卡声称顾客是 VIP，那么俱乐部可以做出相应的反应，将经过验证的 VIP 会员资格声明转化为许可，例如允许顾客坐在专属休息区并享受免费饮料。”
Considering that a claim is an attribute that tells you something about the user (the name, age, ethnicity, etc) you work against a security token service to validate those claims and also used them for authorization apart from authentication.
The following excerpt is taken from Wikipedia (http://en.wikipedia.org/wiki/Claims-based_identity) and its the best analogy I found so far
"To better understand the concept of security token service, consider the analogy of a night club with a doorman. The doorman wants to prevent under-age patrons from entry. To facilitate this he requests a patron to present a driver's license, health insurance card or other identification (the token) that has been issued by a trusted third party (the security token service) such as the provincial or state vehicle license department, health department or insurance company. The nightclub is thus alleviated of the responsibility of determining the patron's age. It only has to trust the issuing authority (and of course make its own judgment of the authenticity of the token presented). With these two steps completed the nightclub has successfully authenticated the patron with regard to the claim that he or she is of legal drinking age.
Continuing the analogy, the nightclub may have a membership system, and certain members may be regular or VIP. The doorman might ask for another token, the membership card, which might make another claim; that the member is a VIP. In this case the trusted issuing authority of the token would probably be the club itself. If the membership card makes the claim that the patron is a VIP, then the club can react accordingly, translating the authenticated VIP membership claim to a permission such as the patron being permitted to sit in the exclusive lounge area and be served free drinks."