使用PrincipalPermission实施正确的IPrincipal和IIdentity

Question

我已根据定义有效身份及其权限的网站定义了自定义IPrincipal和自定义IIdentity。这两个类都用于Windows窗体应用程序中使用的程序集。

问题是，在我的程序集类之上使用声明性PrincipalPermission属性时，如何强制执行我的自定义IPrincipal和IIdentity类，而不是其他可能经过身份验证的IPrincipal / IIdentity。

[PrincipalPermission(SecurityAction.Demand, Authenticated = true, Role = "limited")]
public class RequiresAuthentication
{ }

Answer 1

你不能强制执行 - 这是编程到界面而不是具体类的全部要点。

PrincipalPermission（和PrincipalPermissionAttribute）适用于Thread.CurrentPrincipal，因为它跟在Liskov Substituion Principle之后，它会平等地处理所有IPrincipal实例。

如果你真的必须确保只能使用自己的自定义IPrincipal，你可以编写自己的CustomPrincipalPermission来模仿PrincipalPermission的行为。

Answer 2

安全感知代码分为两部分：识别方（IP），用于对用户进行身份验证并生成IIdentity和IPrincipal个对象，以及依赖方（RP），它使用它们。

在RP中，您无需关心IPrincipal来自哪里，只要它有效。

您可以自己编写IP来控制权限的来源。这样，您就可以确保只生成自定义IIdentity和IPrincipal个对象。

如果你打电话给别人的IP，那么你根据定义并不关心生成什么类型​​的IPrincipal。

修改

然而，话虽如此，还存在一个额外的问题，即一个名为"limited"的角色可能由几个不同的IP生成，并且每个IP的含义都不同。解决该问题的方法是使用基于声明的主体而不是基于角色的主体。声明不是简单的字符串，而是由命名空间URI进行数字签名和标识的通用数据值。这样，您仍然不关心哪个IPrincipal被提供给您，但您可以保证声明是正确的，即使其名称与来自其他IP的其他声明冲突。

查看基于声明的安全性的新Windows Identity Foundation（以前称为日内瓦，以前称为Zermatt）。

Answer 3

我们使用自定义主体和自定义权限/属性做同样的事情。

您可以创建一个派生自CodeAccessSecurityAttribute的新属性，并实现CreatePermission以返回您自己的权限实例（派生自IPermission和IUnrestrictedPermission）基于角色的检查。然后使用您自己的属性而不是标准属性标记方法。这样做的一个优点是你可以使用枚举作为角色而不是在整个代码中散布魔法字符串。

[MyPrincipalPermission(SecurityAction.Demand, Roles = MyRoles.Limited)]
public void Foo() { ... }

创建自己的权限很难，让所有Intersect，Union等方法工作和测试真的很复杂，所以如果你打算去这个然后路线分配在2-5天的某个地方，以确保它坚如磐石。