logo标签列表

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

asp.netauthenticationasp.net-membershipauthorizationazman
39
我们开始设计一批新服务，包括（WCF，ADO.NET数据服务，可能在云中），但一个问题出现了，那就是使用哪种身份验证和授权方案 - 有相当多的选择！我们基本上需要能够在各种协议上识别用户（实际人员和"虚拟"应用/服务用户） - HTTP、HTTPS、TCP，并且我们需要分配给他们至少一些角色/权限，以查看特定的数据和/或执行某些操作。
我们绝对不能单独使用Windows组成员资格 - 我们有大量的服务外部使用者，我们不想为他们每个人在内部域中设置域帐户。
所以主要有三个选项：
1. 使用ASP.NET会员系统 - 在那里创建用户并分配角色 2. 使用 AzMan（授权管理器），它似乎是一个更加精细、更加成熟、更加复杂的系统（具有用户、任务、组-三个级别，而不仅仅是用户+角色） 3. 自己编写
首先 - 你会推荐这三个选项中的哪一个？任何原因？
其次 - 我错过了其他的选择吗？
谢谢任何提示、指针和意见！
马克
PS: 看到目前为止的答案，我对第3个选项的投票数量感到惊讶。我本以为微软能够设计出可重复使用的东西，可以处理所有这些要求....
8个回答
19
实际上，答案可能是1和3的结合。
如果默认选项不够用，您可以通过编写membership、role或profile提供程序来利用框架为您提供的许多工具和功能。
我们在许多客户网站上都这样做了——例如，我们的一个客户将大多数用户存储为Commerce Server用户，并使用Commerce Server配置文件系统，因此我们编写了会员资格和配置文件提供程序来与这些数据存储进行通信——这是一个相当简单的练习。
由于需要在原始TCP上进行身份验证，大多数人可能会选择3，这引入了超出标准ASP.NET成员提供程序的层次。
微软生产的大部分内容都是“可以”的或“足够好的”，但总会有一些边缘情况，你想做一些“不太标准”的事情，这意味着你最终要自己编写。我猜为了让普通开发人员更容易理解，除了“基本认证”或“Windows认证”之外，他们采取了明智的“让我们为Web构建这个简单的东西”。
如果您看一下您可以对WCF服务进行身份验证的众多方式，您就会明白我的意思 - 这些是设计用于处理不同的传输机制，因此更加复杂。
话虽如此，默认的角色和配置文件提供程序相当有限（角色：没有层次结构，因此您需要检查每个可能的角色，或明确地将每个角色分配给用户；配置文件：所有存储在一个字段中作为逗号分隔值 - 不容易找到设置了值的所有用户）。
6

我们使用(3)。实际上，在集成场景中，这有助于我们将帐户与以下内容同步：

  1. 业务流程
  2. 其他系统（不都是基于ASP.NET技术堆栈的）
3
在最近的项目中，我们扩展了ASP.NET成员资格提供程序（编写了自定义提供程序），旨在使用一些基于角色的控件来管理权限。现在，该项目已经足够成熟，我们发现这些控件对于我们的要求不够灵活，并且在某种程度上我们后悔走了MS成员资格的路线。如果您有时间正确地设计它，自己编写身份验证将是最好的选择。
听起来您的应用程序有点混合，因为您为内部和外部客户提供服务，但也考虑将OpenID集成到外部客户端。有一些很棒的ASP.NET OpenID控件，可以让处理外部客户新帐户变得轻而易举。当然，这取决于您的应用程序有多“公开”。
+1 for OpenID - 这是一个非常有趣的想法 - 谢谢！ - marc_s
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

}

真的吗？请求一个全面、完整且易于使用的解决方案来了解自己是谁以及自己能做什么，这真的太过分了吗？我认为这几乎是当今任何应用程序的基石，不是吗？ - marc_s
代码只是基本属性的示例，用户对象可以根据需要添加更多属性，并创建一些插件模型。我的观点是您必须拥有自己的User类（或者根据为这些用户提供的服务从Microsoft的某个User类中派生它）。 - Yordan Georgiev
这是一个从MembershipUser类派生的示例 - http://msdn.microsoft.com/en-us/library/ms366730.aspx - Yordan Georgiev
1

Ldap 有人用过吗？它是免费的、跨平台的，易于远程使用和管理，可以与其他认证方案桥接，并且在更多你所不知道的语言中都有绑定...

我们现在基本上和Active Directory处于同一位置，对吧？我们需要在LDAP中为任何用户（真实或虚拟）创建用户帐户，是吗？您认为与其他选项相比有什么好处？ - marc_s
另外，据我所了解（如果我错了，请纠正我），LDAP实际上只处理身份验证部分 - 你是谁？还是有一种简单的方法将授权包含在其中呢？（作为用户，您可以做什么？） - marc_s
ASP.NET会员资格难道不也提供了与AD集成的选项吗？ 例如，LDAP允许数据源在Novell或Linux系统上，而在这些系统上模拟AD将是一项艰苦的工作 - 即使有100％的匹配也难以实现。 - Sascha
LDAP为Web应用程序增加了另一个动态组件，如果您使用AD LDAP存储，则通过允许Web应用程序添加可能在Windows网络上有效的身份验证凭据，会使您的公司数据面临不必要的风险。 - Don Werve
1

AZMan不是来自2003年吗？

我建议选择1或3。个人而言，我一直选择3。1有很多功能，但我不使用或关心它们。

1
我建议远离AzMan。我们曾经尝试过，但并不喜欢我们被困在那个区域的感觉。我们一直使用基于AD的登录方式，使用当前用户的SID链接到数据库中的用户，然后从那里获取权限。考虑到您的设置，这可能不可行（或不切实际），但无论如何，我都建议远离AzMan。
我们一直在使用AzMan。沿途遇到了一些问题，但都不是无法解决的... - Calanus
1

我不是ASP或.NET开发人员，但我的直觉告诉我（3）。您真的不希望公共使用的Web应用程序能够访问您的企业网络，更不用说能够将授权凭据放在AD附近了。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接