我需要知道如何去为C＃应用程序中实现普遍安全。 哪些选项我在这方面？ 我宁愿它是否符合我的需要使用现有的框架 - 我不想重新发明轮子。
我的要求如下：
我要寻找一个自由/开放源码框架/库，已经时间tesed和.NET社区使用。
我的应用程序需要一个客户端/服务器方式，与运行作为Windows服务的服务器，连接到SQL Server数据库。 客户端和服务器之间的通信将通过WCF。
这是很重要的一件事是，我需要能够给特定用户或角色的权限分配给查看/更新/删除特定的实体，无论是客户或产品等。例如，杰克可以查看某些10的3客户，但只更新客户微软，雅虎和谷歌的细节，只能删除雅虎。
对于粗粒度的安全，你可能会发现有用的内置主代码; 用户对象（以及它们的角色）在.NET由“主”控制，但有效的运行时本身可以执行这一点。
主要的实现可以实现定义的，并且通常可以注入自己; 例如，在WCF 。
看运行时执行粗访问（即， 功能性可以被访问，但不限于特定数据 ）：
static class Roles {
public const string Administrator = "ADMIN";
}
static class Program {
static void Main() {
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Fred"), new string[] { Roles.Administrator });
DeleteDatabase(); // fine
Thread.CurrentPrincipal = new GenericPrincipal(
new GenericIdentity("Barney"), new string[] { });
DeleteDatabase(); // boom
}
[PrincipalPermission(SecurityAction.Demand, Role = Roles.Administrator)]
public static void DeleteDatabase()
{
Console.WriteLine(
Thread.CurrentPrincipal.Identity.Name + " has deleted the database...");
}
}
然而，这并不与细粒度访问帮助（即“弗雷德可访问客户A，但没有客户B”）。
额外; 当然，细粒度，你可以简单地检查所需的角色在运行时，通过检查IsInRole的本金：
static void EnforceRole(string role)
{
if (string.IsNullOrEmpty(role)) { return; } // assume anon OK
IPrincipal principal = Thread.CurrentPrincipal;
if (principal == null || !principal.IsInRole(role))
{
throw new SecurityException("Access denied to role: " + role);
}
}
public static User GetUser(string id)
{
User user = Repository.GetUser(id);
EnforceRole(user.AccessRole);
return user;
}
您也可以编写自己的本金/身份对象做角色的懒惰测试/高速缓存，而不必知道他们所有的前期：
class CustomPrincipal : IPrincipal, IIdentity
{
private string cn;
public CustomPrincipal(string cn)
{
if (string.IsNullOrEmpty(cn)) throw new ArgumentNullException("cn");
this.cn = cn;
}
// perhaps not ideal, but serves as an example
readonly Dictionary<string, bool> roleCache =
new Dictionary<string, bool>();
public override string ToString() { return cn; }
bool IIdentity.IsAuthenticated { get { return true; } }
string IIdentity.AuthenticationType { get { return "iris scan"; } }
string IIdentity.Name { get { return cn; } }
IIdentity IPrincipal.Identity { get { return this; } }
bool IPrincipal.IsInRole(string role)
{
if (string.IsNullOrEmpty(role)) return true; // assume anon OK
lock (roleCache)
{
bool value;
if (!roleCache.TryGetValue(role, out value)) {
value = RoleHasAccess(cn, role);
roleCache.Add(role, value);
}
return value;
}
}
private static bool RoleHasAccess(string cn, string role)
{
//TODO: talk to your own security store
}
}
看看ASP.NET的会员供给者 。 我不认为开箱SqlMembershipProvider的将在你的情况下工作，但它是很容易推出自己的供应商。
my answer is probably dependent upon the answer to this question: Is this an Enterprise application which lives within a network with Active Directory?
IF the answer is yes, then these are the steps I would provide:
1) Create Global Groups for your application, in my case, I had a APPUSER group and an APPADMIN group.
2) Have your SQL Server be able to be accessed in MIXED AUTHENTICATION mode, and then assign your APPUSER group(s) as the SQL SERVER LOGIN to your database with the appropriate CRUD rights to your DB(s), and ensure that you access the SQL SERVER with Trusted Connection = True in your connection string.
At this point, your AD store will be responsible for authentication. Since, you're accessing the application via a TRUSTED CONNECTION, it will pass the identity of whatever account is running the application to the SQL Server.
Now, for AUTHORIZATION (i.e. telling your application what the logged in user is allowed to do) it's a simple matter of querying AD for a list of groups which the logged in user is a member of. Then check for the appropriate group names and build your UI based upon membership this way.
The way my applications work are thus:
I then have either a PRINCIPLE object with the determined rights/etc on it, or I utilize GLOBAL variables that I can access to determine the appropriate UI while building my forms (i.e. if my user is not a member of the ADMIN group, then I'd hide all the DELETE buttons).
Why do I suggest this?
It's a matter of deployment.
It has been my experience that most Enterprise Applications are deployed by Network Engineers rather than programmers--therefore, having Authentication/Authorization to be the responsibility of AD makes sense, as that is where the Network guys go when you discuss Authentication/Authorization.
Additionally, during the creation of new users for the network, a Network Engineer (or whoever is responsible for creating new network users) is more apt to remember to perform group assignments while they are IN AD than the fact that they have to go into a dozen applications to parse out assignments of authorization.
Doing this helps with the maze of permissions and rights that new hires need to be granted or those leaving the company need to be denied and it maintains authentication and authorization in the central repository where it belongs (i.e. in AD @ the Domain Controller level).
我想看看像CSLA.net： 专家C＃2008 Business Objects公司
它应该提供您所需要的一切。
WCF拥有丰富的安全相关的功能提供授权和认证。 在这里详细信息： http://msdn.microsoft.com/en-us/library/ms735093.aspx
我认为你正在寻找在这里的几个不同的问题 - 这不是偶然的最安全系统分离认证和授权。
对于身份验证，更大的问题是后勤。 或者，有没有为这些用户在本地生活，是它的应用程序，在Active Directory中，一些其他的LDAP存储或者甚至在一些其他的应用程序逻辑的地方。 究竟在何处是非常不重要的 - 我们只需要能够牢固地识别用户，最好让该任务别人的问题。 一天结束时，你真的只需要一个唯一的标识符和舒适鲍勃从会计实际上是从会计鲍勃。
授权是问题的更有趣的部分在这里。 我想，如果是真正细粒度，你真的想在用户来自您的应用程序内全部来管理这个，不管。 马克Gravell真的打一个很好的方式来建模至少一些本 - 使用的IPrincipal和中的PrincipalPermission一些自定义的实现来管理的事情是开始一个非常干净的方式。 除此之外，你可以使用技术，像这样一个在一个相当干净的方式，使更多复杂的授权决定。
我会用这个词 - “RBAC”（基于角色的访问控制系统）作为解决您的所有需求。
我不会太多细节去解释“RBAC”在这里，而我会简单地描述为：
它基本上包含3种功能。
1）认证 - 它确认用户的身份。 通常它是通过用户帐户和密码或证书来完成。
2）授权 - 它定义哪些用户可以做，在应用程序中无法做到的。 防爆。 “修改为了”被允许的，但“创造新的秩序”是不允许的。
3）上的应用程序的用户动作的审计。 - 它使对应用程序跟踪用户的行为，以及谁授予其访问哪些用户？
你可以在维基检查RBAC这里。
https://en.wikipedia.org/wiki/Role-based_access_control
现在，关于回答您的需求 - 可能的解决方法之一是扩大ASP.NET成员按您的需求。
而对于一些准备使用的框架，我会建议VisualGuard为我工作，你应该检查这一点，它做了所有的事情，你需要的东西很容易，而最重要的是，它可以管理所有用户，角色，权限，并通过中央管理控制台应用程序，以及定义权限，管理员不需要开发人员的知识，即他/她可以通过UI创建活动的限制。
您还可以查看这篇文章，具有权限和基于角色的系统更多的了解。
http://www.visual-guard.com/EN/net-powerbuilder-application-security-authentication-permission-access-control-rbac-articles/dotnet-security-article-ressources/role-based-access-control- source_soforum.html
