39

我们开始设计一大堆要创建的新服务（WCF、ADO.NET 数据服务，可能在某个时候在云中），弹出的一个问题是使用什么身份验证和授权方案 - 有很多很少！

我们基本上需要能够识别各种协议（HTTP、HTTPS、TCP）上的用户（实际人员和“虚拟”应用程序/服务用户），并且我们需要为他们分配至少一堆角色/权限查看某些数据和/或执行某些操作。

我们绝对不能单独使用 Windows 组成员资格 - 我们有大量服务的外部消费者，我们不希望必须在我们的内部域中为每个人设置域帐户。

所以我认为主要有三个选择：

  1. 使用 ASP.NET 成员系统 - 在那里创建用户并分配角色
  2. 使用 AzMan（授权管理器），它似乎是一个更细粒度、更成熟、更精细的系统（具有用户、任务、组 - 三个级别，而不仅仅是用户 + 角色）
  3. 滚动我们自己的

首先 - 你会推荐这三个中的哪一个？有什么理由吗？

其次 - 我还有更多的选择吗？

感谢您的任何提示，指针，意见！

马克

PS：看到到目前为止的答案，我对投票给选项#3 的人数之多感到惊讶。我原以为 MS 能够设计出可以处理所有这些要求的可重复使用的东西......

4

8 回答 8

19

实际上，答案可能是 1 和 3 的组合。

如果默认选项没有达到您想要的程度，您可以通过编写成员资格、角色或个人资料提供者来利用框架为您提供的许多工具和功能。

我们已经在许多客户网站上做到了这一点 - 例如，我们的一个客户将他们的大部分用户存储为 Commerce Server 用户，并使用 Commerce Server 配置文件系统，因此我们编写了一个会员和配置文件提供程序来与这些用户交谈数据存储 - 一个相当简单的练习。

大多数人可能会选择 3，因为需要通过原始 TCP 进行身份验证——这引入了一个超出标准ASP.NET成员资格提供程序的层。

MS 生产的大部分产品都是“好的”或“足够好”，但总会有一些极端情况，你想做一些“不太标准”的事情，这意味着你最终会自己动手。我猜想除了“基本身份验证”或“Windows 身份验证”之外，您的普通开发人员很容易理解，他们选择了“让我们为网络构建这个”的明智选择。

如果您看一下可以针对 WCF 服务进行身份验证的多种方法，您就会明白我的意思——这些方法旨在处理不同的传输机制，因此要复杂得多。

也就是说，默认角色和配置文件提供者相当有限（角色：没有层次结构，因此您需要检查每个可能的角色，或将每个角色显式分配给用户；配置文件：所有存储在一个字段中作为逗号分隔值 - 不是很容易找到所有设置了值的用户）。

于 2009-04-16T19:14:11.803 回答
6

我们使用（3）。实际上，这有助于我们在整合环境中拥有同步的帐户

  1. 业务流程
  2. 其他系统（并非都在同一个技术栈 (ASP.NET) 上）
于 2009-04-16T18:42:48.133 回答
3

在最近的一个项目中，我们扩展了 ASP.NET 成员资格提供程序（编写了一个自定义提供程序），目的是使用一些基于角色的控件来管理权限。现在该项目已经足够成熟，我们发现控制不够灵活，无法满足我们的要求，并且在某种程度上我们对走 MS 会员资格的道路感到遗憾。如果您有时间正确构建身份验证，则滚动您自己的身份验证将是最佳选择。

听起来您的应用程序有点混合，因为您正在为内部和外部客户提供服务，但也许还要考虑为您的外部客户集成OpenID。有一些很棒的 ASP.NET OpenID 控件可以真正让为外部客户处理新帐户变得轻而易举。这当然取决于您的应用程序的“公开”程度。

于 2009-04-16T20:41:38.457 回答
1

有人吗？它是免费的，跨平台的，易于远程使用和管理，具有与其他身份验证方案的桥梁，以及您知道存在的更多语言的绑定......

于 2009-04-16T18:38:44.023 回答
1

AZMan 不是 2003 年的吗？

我会推荐 1 或 3。就我个人而言，我一直选择 3。1 有很多我不使用或不打算使用的功能。

于 2009-04-16T18:44:05.243 回答
1

我会远离阿兹曼。我们曾经走过那条路，不喜欢我们所在的城镇区域。我们总是使用基于 AD 的登录，使用当前用户的 SID 链接到数据库中的用户，然后获取权限从那里。鉴于您的设置，这可能是不可能的（或实际的），但无论如何我都会远离 AzMan。

于 2009-04-16T18:46:15.707 回答
1

我不是 ASP 或 .NET 开发人员，但我的直觉告诉我 (3)。您真的不希望公共使用的网络应用程序可以访问您的公司网络，更不用说能够将身份验证凭据放在 AD 附近的任何地方。

于 2009-04-16T18:58:33.697 回答
1

您似乎提供了太多且太可扩展而无法坚持一种技术解决方案

解决方案 3。

我将围绕用户类建立整个应用程序您只需对其进行建模，以便为您提供所需的灵活性和可扩展性

就像是：

    [ClassAttribute ( "Yordan Georgiev", "1.0.2", "20090302", "20090415" , false )]
public class User
{
    #region DomainName
    private string _DomainName;
    public string DomainName
    {
        get { return _DomainName; }
        set { _DomainName = value; }
    } //eof property DomainName 


    #endregion DomainName

    #region Status
    private int _Status;
    public int Status
    {
        get { return _Status; }
        set { _Status = value; }
    } //eof property Status 


    #endregion Status

#region Password
    private string _Password = Resources.GV.Pass; 
    public string Password
    {
        get { return _Password; }
        set {
            _Password = GenApp.Utils.Security.Encryptor.Encrypt ( value,
                GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm );
            //debug_Password = value; //unencrypted 
        }
    } //eof property Password 


    #endregion Password 

#region ListUserRoles
        private List<UserRole> _ListUserRoles;
        public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set     { _ListUserRoles = value; } }
        #endregion ListUserRoles


    #region UserSettings
    private GenApp.Conf.UserSettings _UserSettings;
    public GenApp.Conf.UserSettings UserSettings
    {
        get {
            if (_UserSettings == null)
                _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance;

            return _UserSettings; 
        }
        set { _UserSettings = value; }
    } //eof property UserSettings

}

于 2009-04-16T19:01:19.477 回答