Asp.net 使用程序集从控制台应用程序强制实施基于声明的授权

我目前正在（向现有应用程序）引入一个自定义权限系统，该系统将声明（来自web应用程序中基于WSFed的OWIN auth）提供的角色映射到应用程序本身中定义的权限

目前，计划是将权限系统直接返回到线程主体上

这些权限已验证：

• 在web UI中
• 在业务层（如果是未来的替代UI）

然而，目前尚不清楚的是，有一个控制台应用程序作为计划任务运行，它使用与web应用程序相同的业务层类（相同的程序集引用）。该应用程序在单独域中的本地Windows用户下运行，该域没有所需的角色（因此将无法授权）

我可以看到一些解决此问题的方法：

复制Windows计算机中的角色，并将其分配给运行console应用程序的系统用户

修改console应用程序，将声明显式添加到所使用的标识中

修改权限系统，使其具有某种覆盖和/或从控制台应用程序注入“无用”权限系统

---

这些似乎都不是特别优雅的解决方案。考虑到这一点，我的问题很简单：在这种情况下，在身份到授权的上下文中是否有一种规范化的方法？

非常有趣的问题，我没有意识到真正的规范化答案

我会选择1或2，这取决于你们的情况。如果要处理客户端的身份验证逻辑，您的控制台应用程序只是另一个客户端，它需要具有在系统中执行操作的权限。仅为客户端修改权限系统可能会打开安全漏洞，对于具有权限的客户端来说，这听起来像是对逻辑的攻击

现在介于1和2之间-这取决于您正在处理的情况。如果客户端需要多次部署或由您的客户部署，为了部署的简单性，我会破解命令行应用程序，并在那里向委托人添加所需的声明

如果您的命令行客户端用于私人消费，并且不需要多次部署，最简单的方法是让一个单独的域用户拥有对该用户的所有必需权限，并从该用户运行应用程序。如果您需要在不更改命令行应用程序代码的情况下更改应用程序用户的权限，这将使权限与应用程序分离，并使您的生活更轻松

---

这些纯粹是我的猜测，我希望会有其他意见。

最终我决定越简单越好。我设置了我的权限服务，这样就可以将

IPrincipal

注入ctor，并从控制台应用程序注入具有完全权限的伪主体。@这是“惯用并不总是最好”的一个很好的例子。很高兴你找到了解决问题的好办法。