你正在使用哪种authentication和授权scheme – 为什么?

我们开始devise一些新的服务来创build(WCF,ADO.NET数据服务,可能在某个时候在云端),popup一个问题是使用什么authentication和授权scheme – 几个!

我们基本上需要能够根据各种协议(HTTP,HTTPS,TCP)来识别用户(实际的人员和“虚拟”应用/服务用户),并且我们需要为他们分配至less一堆angular色/权限看到某些数据和/或做某些操作。

我们绝对不能单独使用Windows组成员身份 – 我们有大量的服务外部消费者,我们不希望为每个人在我们的内部域中build立一个域帐户。

所以主要有三个select,我想:

  1. 使用ASP.NET成员资格系统 – 在那里创build用户并分配angular色
  2. 使用AzMan(授权pipe理器)似乎是一个更细化,更成熟,更精细的系统(用户,任务,组 – 三个级别,而不仅仅是用户+angular色)
  3. 滚我们自己的

首先 – 你推荐哪三个? 任何为什么?

其次 – 有更多的select,我错过了?

感谢任何提示,指针,意见!

渣子

PS:到目前为止看到的答案,我很惊讶的人数投票选项#3。 我会认为,MS将能够devise可以处理所有这些要求的可重用的东西….

其实答案可能是1和3的组合。

如果默认选项没有达到您想要的程度,您可以通过编写成员资格 , angular色或configuration文件提供程序来充分利用框架为您提供的许多工具和function。

我们在很多客户站点上都做了这个,例如我们的一个客户把他们的大部分用户存储为Commerce Server用户,并使用Commerce Serverconfiguration文件系统,所以我们写了一个成员资格和configuration文件提供程序来与那些数据存储 – 一个相当简单的练习。


由于需要通过原始TCP进行身份validation,因此大多数人可能会使用3个,这会引入超出标准ASP.NET成员资格提供程序的层。

MS所产生的大部分是“好的”或“足够好的”,但总会有边缘情况,你想要做一些“不太标准”的事情,这意味着你最终会滚动自己。 我想除了“基本authentication”或“Windowsauthentication”以外,对于普通开发人员来说,理解起来很简单,他们采取了“让我们只为networking构build”的明智select。

如果您看看可以通过WCF服务进行身份validation的众多方式,您将会看到我的意思 – 这些旨在处理不同的传输机制,因此更为复杂。

也就是说,默认的angular色和configuration文件提供者是相当有限的(angular色:没有层次结构,所以你需要检查每个可能的angular色,或明确分配每个angular色的用户;configuration文件:所有存储在一个字段中,作为逗号分隔值 – 不很容易find所有有价值的用户)。

我们使用(3)。 其实那帮助我们在一个融合景观有同步的帐户

  1. 业务stream程
  2. 其他系统(并不都在同一个技术栈(ASP.NET)上)

在最近的一个项目中,我们扩展了ASP.NET成员资格提供者(编写了一个自定义提供者),目的是使用一些基于angular色的控件来pipe理权限。 现在项目已经成熟了,我们发现这些控件对于我们的需求来说还不够灵活,在某种程度上我们对MS的成员资格path感到遗憾。 如果您有时间正确地构build它,那么滚动自己的身份validation将是最好的select。

这听起来像是你的应用程序有点混合,因为你正在为内部和外部客户服务,但也可能考虑为你的外部客户集成OpenID 。 有一些伟大的ASP.NET OpenID控件真的使处理新的帐户为外部客户一个明智之举。 这当然取决于你的申请是如何“公开”的。

Ldap任何人? 它是免费的,跨平台,易于使用和远程pipe理,桥梁到其他authentication计划,并绑定更多的语言,你知道存在…

从2003年不是AZMan?

我会推荐1或3.就个人而言,我一直是为3.有很多function,我有一个我不使用或照顾使用。

我会远离AzMan。 我们沿着这条路走了一圈,不喜欢我们分手的城镇。我们总是使用基于AD的login方式,使用当前用户的SID链接到数据库中的用户,然后取得权限从那里。 鉴于你的设置这可能是不可能的(或实际),但我会远离AzMan在任何情况下。

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

你似乎提供了太多而且太可扩展的东西来坚持一种技术解决scheme

解决scheme3。

我将整个应用程序基于一个用户类你只需要简单地build模它,以便它将为您提供所需的灵活性和可扩展性

就像是:

[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 

}