如何管理用户索赔？
How to manage user claims?
我目前正在设计一个使用 asp.net 核心的系统，我想实现基于声明的授权，但有一个特定的部分让我感到困惑。
提出索赔时，索赔将包括类型和价值以及可选的发行人。在处理程序中，可以在确认访问之前检查此声明和颁发者。
但是这个颁发者没有存储在身份数据库中，那么处理程序如何检查颁发者？
我是不是误解了这一切是如何运作的？我的理解是，用户提出某种类型的声明，他们的声明具有一定的价值，而发行者是声明类型的验证者，实际上对该用户具有该价值。
处理程序将检查该值并可能检查发行者，但当数据库不存储它时它不能。不明白楼主的意思
我希望用户拥有一组声明，包括 who/what 验证这些声明并让应用程序能够随时验证这些声明。
请帮我理解。
我已经这样测试过：
- 使用带有 Identity 的 asp.net 核心应用程序。
- 注册用户。
- 向包含类型、值和颁发者的用户添加声明。 （例如，EmployeeNumber、312、Microsoft。
- 在 controller/action 上添加 [Authorize(Policy="MicrosoftEmployeesOnly")] 以限制访问。
- 根据要求将策略添加到 StartUp.cs 中的服务中。
- 添加具有处理程序的要求代码，该处理程序检查用户是否拥有类型为 EmployeeNumber 的声明、具有值且由 Microsoft 发布。
- 登录和用户声明将从数据库加载到身份中。
- 处理程序将无法验证用户，因为颁发者 (Microsoft) 已丢失，现在只显示本地权限。
我在这里唯一能想到的是，一旦将声明添加到数据库中，它就被视为已通过 Microsoft 验证，现在由代表 Microsoft 的应用程序（本地机构）持有。
如果是这样的话：
- 为什么要在任何处理程序中检查发行者？
- 如何撤销声明？
我希望能够有选择地前往该发行人并在我需要时检查索赔，这意味着发行人可以 revoke/invalidate 索赔。该员工声称他们在 Microsoft 有一个员工编号，Microsoft 最初对此进行了验证。一段时间后，Microsoft 将该员工踢出并在他们的系统上将其删除。该应用程序应该能够在用户每次登录时与 Microsoft 核实，以查看声明是否有效。在这种情况下，它将不再有效。
我是不是有点生气了？
在您链接到这个问题时将其张贴在这里 from my blog，它可能对某些人有用
I think you have misunderstood slightly about the nature of a claim,
which I can understand given the terminology. You seem to be taking
'Claim' as meaning the user is 'professing' that they have a certain
attribute, and you want to check that this is true.
That is not the way claims work here. Claims are essentially
'attributes' of the user. In the old way of working with roles, a user
would belong to a certain number of roles. These are just 'attributes'
the user has now, so are more generic. A user may have a number of
claims corresponding to the roles they are in.
The identity of the user is checked during authentication, and at that
point you assign the set of Claims that the user has to the
ClaimsIdentity object. This is the point you fetch the claims from
the database, and make sure they only get the ones they should have.
If you need to have someone verifying claims, then you would need to
have that whole process happening outside of this. Only the claims
which have been confirmed should be added to the ClaimsIdentity.
Now, there is an event you can handle on the
CookieAuthenticationMiddleware to validate a security ticket when it
is loaded on subsequent requests called ValidatePrincipal, but I'm not
sure if this is actually what you need.
您随后的回复：
Thank you for your response. I understand now that these claims are
effectively verified claims once they get into the db. I guess they
could be removed from the db as a way of revoking the claim.
However, I think, as you suggest, the best way is to have this system
outside and it just provides claims as and when required. The design
is that the application will have accounts for different types of
entity and accounts will be able to make claims, for example that "I
am a parent". The parent would seek an authorizing account to validate
this. This might require the authorizing account holder to actually
see some real documentation before validating. Other claims, could
change. For example a parent with Parental Responsibility would need a
bit more verification, but may also lose that Parental Responsibility
in the real world and so a facility for revoking the claim needs to be
available.
So, I think the design should be to use the claims system with the
Authorize attribute following your excellent articles, but have a
separate system that allows for validation and revoking that feeds
that claims system.
我目前正在设计一个使用 asp.net 核心的系统，我想实现基于声明的授权，但有一个特定的部分让我感到困惑。
提出索赔时，索赔将包括类型和价值以及可选的发行人。在处理程序中，可以在确认访问之前检查此声明和颁发者。
但是这个颁发者没有存储在身份数据库中，那么处理程序如何检查颁发者？
我是不是误解了这一切是如何运作的？我的理解是，用户提出某种类型的声明，他们的声明具有一定的价值，而发行者是声明类型的验证者，实际上对该用户具有该价值。
处理程序将检查该值并可能检查发行者，但当数据库不存储它时它不能。不明白楼主的意思
我希望用户拥有一组声明，包括 who/what 验证这些声明并让应用程序能够随时验证这些声明。
请帮我理解。
我已经这样测试过：
- 使用带有 Identity 的 asp.net 核心应用程序。
- 注册用户。
- 向包含类型、值和颁发者的用户添加声明。 （例如，EmployeeNumber、312、Microsoft。
- 在 controller/action 上添加 [Authorize(Policy="MicrosoftEmployeesOnly")] 以限制访问。
- 根据要求将策略添加到 StartUp.cs 中的服务中。
- 添加具有处理程序的要求代码，该处理程序检查用户是否拥有类型为 EmployeeNumber 的声明、具有值且由 Microsoft 发布。
- 登录和用户声明将从数据库加载到身份中。
- 处理程序将无法验证用户，因为颁发者 (Microsoft) 已丢失，现在只显示本地权限。
我在这里唯一能想到的是，一旦将声明添加到数据库中，它就被视为已通过 Microsoft 验证，现在由代表 Microsoft 的应用程序（本地机构）持有。
如果是这样的话：
- 为什么要在任何处理程序中检查发行者？
- 如何撤销声明？
我希望能够有选择地前往该发行人并在我需要时检查索赔，这意味着发行人可以 revoke/invalidate 索赔。该员工声称他们在 Microsoft 有一个员工编号，Microsoft 最初对此进行了验证。一段时间后，Microsoft 将该员工踢出并在他们的系统上将其删除。该应用程序应该能够在用户每次登录时与 Microsoft 核实，以查看声明是否有效。在这种情况下，它将不再有效。
我是不是有点生气了？
在您链接到这个问题时将其张贴在这里 from my blog，它可能对某些人有用
I think you have misunderstood slightly about the nature of a claim, which I can understand given the terminology. You seem to be taking 'Claim' as meaning the user is 'professing' that they have a certain attribute, and you want to check that this is true.
That is not the way claims work here. Claims are essentially 'attributes' of the user. In the old way of working with roles, a user would belong to a certain number of roles. These are just 'attributes' the user has now, so are more generic. A user may have a number of claims corresponding to the roles they are in.
The identity of the user is checked during authentication, and at that point you assign the set of
Claimsthat the user has to theClaimsIdentityobject. This is the point you fetch the claims from the database, and make sure they only get the ones they should have. If you need to have someone verifying claims, then you would need to have that whole process happening outside of this. Only the claims which have been confirmed should be added to theClaimsIdentity.Now, there is an event you can handle on the
CookieAuthenticationMiddlewareto validate a security ticket when it is loaded on subsequent requests called ValidatePrincipal, but I'm not sure if this is actually what you need.
您随后的回复：
Thank you for your response. I understand now that these claims are effectively verified claims once they get into the db. I guess they could be removed from the db as a way of revoking the claim.
However, I think, as you suggest, the best way is to have this system outside and it just provides claims as and when required. The design is that the application will have accounts for different types of entity and accounts will be able to make claims, for example that "I am a parent". The parent would seek an authorizing account to validate this. This might require the authorizing account holder to actually see some real documentation before validating. Other claims, could change. For example a parent with Parental Responsibility would need a bit more verification, but may also lose that Parental Responsibility in the real world and so a facility for revoking the claim needs to be available.
So, I think the design should be to use the claims system with the Authorize attribute following your excellent articles, but have a separate system that allows for validation and revoking that feeds that claims system.