我一直在阅读基于角色的访问控制，我正在试图弄清楚如何实施安全控制。在我的MEF项目中，我有一个安全控制器，最终负责用户验证，验证角色等。
当然，安全控制器需要能够访问数据库以对用户运行验证并检索用户的角色。我打算从System.Security.Principal命名空间实现类。
安全控制器模块是否应该拥有自己的数据库，其中用户信息与业务数据分开维护？
并且，只要用户密码（只有散列）没有存储在所述文件中，二进制序列化文件是否足够？ 我会但是，假设为了使其工作，序列化文件必须可由应用程序的多个实例访问...
更新 由于这是一个MEF项目，我一直在想安全应该如何工作。以下是我的想法：
Security Controller本身就是一个Identity对象，因此应该实现IIdentity并具有GenericIdentity属性。 SecControl也应该是GenericPrincipal ...... ???
SecControl还负责修改AppDomain权限集。我不希望任何模块访问SecControl未特别授予的任何资源（数据库，文件，网络共享等）。
不仅用户经过身份验证，而且模块也是如此。模块（插件）可能会实现IIdentity并具有GenericIdentity属性。
答案 0 :(得分：1)
安全控制器模块是否应该拥有自己的数据库，其中用户信息与业务数据分开维护？
取决于您的系统的上下文：
还要考虑你在保护什么。如果您主要是试图保持访问沉闷的咆哮并且不使用财务信息，医疗保健信息或防御信息 - 您可能会在存储用户信息的位置存在一定的风险。如果您拥有高安全性的应用程序，那么您甚至可能想要考虑用于访问控制的纪念软件产品（例如具有自己的审计日志，服务器，管理进程等的LDAP目录）。
当您考虑数据存储时，不要仅仅考虑如何存储和保护数据。还要考虑如何访问数据（通过加密连接或明文？），如何记录访问（在高安全性系统中，验证用户凭据是应该记录的事件），如何保护日志（是防篡改？），以及如何保护数据 - 不仅来自审查，还来自修改。
并且，只要用户密码（只有散列）没有存储在所述文件中，二进制序列化文件是否足够？但是，我认为，为此，序列化文件必须可由应用程序的多个实例访问...
我最大的问题是 - 如何保护此文件免受更改？由于二进制searlized文件相对容易从应用程序解析，如何控制其他进程写入文件的能力？最容易的攻击是添加自己的高权限帐户和用户名/密码哈希，然后使用虚假帐户破解系统的其余部分。这样做有多容易，获取一组低权限凭据并将其转换为高权限是多么容易？
这不仅仅是文件存储机制 - 它还意味着您需要了解操作系统的访问控制以及如何管理它。
可能会有所帮助的事情： - 使用存储在别处的非对称密钥对文件进行数字签名，然后在使用文件之前检查是否存在篡改。 - 将文件存储在只有管理员才能修改的帐户中。