.NET中的身份验证、授权、用户和角色管理和一般安全性

对于粗粒度的安全性,您可能会发现内置的主体代码很有用;用户对象(及其角色)在.NET中由“主体”控制,但运行时本身可以有效地强制实现这一点。

主体的实现可以定义为实现,您通常可以注入自己的主体; for example in 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...");
    }
}

但是,这对细粒度访问没有帮助(即,“Fred可以访问客户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's Membership Providers . 我认为开箱即用的sqlmembershipprovider在您的情况下不会起作用,但它很容易就能滚动您自己的提供程序。

我的答案可能取决于这个问题的答案: 这是否是一个企业应用程序,它位于具有Active Directory的网络中?

如果答案是肯定的,那么我将提供以下步骤:

1)为您的应用程序创建全局组,在我的例子中,我有一个appuser组和一个appadmin组。

2)让您的SQL Server能够以混合身份验证模式访问,然后将您的appuser组作为SQL Server登录名分配给您的数据库,并对您的数据库具有适当的CRUD权限,并确保您可以使用 可信连接=真 在连接字符串中。

此时,您的广告商店将负责身份验证。因为您是通过可信连接访问应用程序的,所以它会将运行应用程序的任何帐户的标识传递给SQL Server。

现在,对于授权(即告诉您的应用程序允许登录的用户做什么),只需查询AD以获取登录用户所属组的列表。然后检查适当的组名,并以这种方式基于成员身份构建您的UI。

因此,我的应用程序的工作方式是:

1. 启动应用程序时,凭据基于登录的用户,这是身份验证的主要方面(即他们可以登录,因此他们存在)
2. 我为有问题的Windows标识获取所有组
3. 我检查标准用户组——如果不存在有问题的Windows标识的这个组,那么这就是身份验证失败。
4. 我检查管理用户组——在用户组中存在这个用户组的情况下,我修改用户界面以允许访问管理组件。
5. 显示用户界面

然后,我拥有一个具有已确定权限的Principle对象/etc,或者我可以在构建表单时使用全局变量来确定适当的UI(即,如果我的用户不是管理组的成员,那么我将隐藏所有删除按钮)。

我为什么建议这样做?

这是一个部署问题。

根据我的经验,大多数企业应用程序都是由网络工程师而不是程序员部署的——因此,将身份验证/授权作为AD的责任是有意义的,正如网络人员在讨论身份验证/授权时所做的那样。

此外,在为网络创建新用户的过程中,网络工程师(或负责创建新网络用户的任何人)更容易记住在AD中执行组分配,而不是必须进入十几个应用程序来解析授权分配。

这样做有助于解决新员工需要被授予或离开公司的员工需要被拒绝的权限和权限迷宫,并在其所属的中央存储库中维护身份验证和授权(即在域控制器级别的AD中)。

我想看看csla.net: Expert C# 2008 Business Objects

它应该提供你所需要的一切。

WCF具有丰富的安全相关功能,可以提供授权和身份验证。 详情如下: http://msdn.microsoft.com/en-us/library/ms735093.aspx

我认为您在这里看到了一些独立的问题——大多数安全系统独立的身份验证和授权并不是偶然的。

对于认证,更大的问题是后勤问题。或者,这些用户是否有合理的居住空间,无论是在应用程序的本地,在Active Directory,其他LDAP存储,甚至在其他应用程序中。确切地说,哪里是无关紧要的——我们只需要能够可靠地识别用户,最好是让任务成为别人的问题。一天结束时,你真的只需要一个唯一的标识符,会计部门的鲍勃实际上就是会计部门的鲍勃。

授权是问题中更有趣的部分。我认为,如果它真的是细粒度的,那么您真的想要在应用程序中完全管理它,不管用户来自哪里。MarcGravell确实找到了一种很好的建模方法——使用一些iprincipal的自定义实现和PrincipalPermission来管理事情是一种非常干净的开始方式。除此之外,你还可以使用诸如 this one 以相当干净的方式做出更复杂的授权决策。

我将使用术语“RBAC”(基于角色的访问控制系统)作为满足您所有需求的解决方案。

在这里,我不会详细解释“RBAC”,而是在下面简单介绍一下。

它基本上包含3个功能。

1)认证-确认用户身份。通常是通过用户帐户、密码或凭据完成的。

2)授权-它定义了用户可以在应用程序中做什么和不能做什么。例如,允许修改订单,但不允许创建新订单。

3)审核用户对应用程序的操作。-它跟踪用户对应用程序的操作,以及谁授予哪些用户访问权?

你可以在wiki上查看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