您使用哪些身份验证和授权方案 - 为什么？

Question

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

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

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

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

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

首先 - 您会推荐这三个级别中的哪一个？ 有什么原因吗？

其次 - 我还缺少更多选择吗？

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

Marc

PS：看到到目前为止的答案，我对投票支持选项#3 的人数量感到惊讶。 我本以为微软能够设计出一些可重复使用的东西来满足所有这些要求......

Answer 1

我们使用（3）。 同步

1. 实际上，这帮助我们在集成环境中使帐户与业务流程
2. 其他系统（并非全部位于同一技术堆栈（ASP.NET）上）

Answer 2

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

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

Answer 3

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

Answer 4

AZMan不是2003年的吗？

我会推荐 1 或 3。就我个人而言，我总是选择 3。1 有很多功能我不使用或不关心使用。

Answer 5

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

Answer 6

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

Answer 7

您似乎提供了太多且太可扩展的内容，以至于无法坚持一种技术解决方案

解决方案 3。

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

例如：

    [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 

}

Answer 8

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

您可以通过编写 会员身份，角色或个人资料提供商（如果默认选项不存在）并没有完全达到你想要的程度。

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

---

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

MS 生产的大多数产品都是“不错”或“足够好”，但总会有一些边缘情况，您想做一些“不太标准”的事情，这意味着您最终会推出自己的产品。 我想除了“基本身份验证”或“Windows 身份验证”之外，还有一些对于普通开发人员来说很容易理解的东西，他们采取了明智的选择“让我们为网络构建这个”。

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

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