什么是身份验证和授权 身份验证和授权介绍【详解】

Posted 2023-03-09

参考技术A 　　什么是身份验证和授权

　　根据RFC2828(Internet Security Glossary，May2000)，验证是“校验被或向某系统实体声明的身份的过程”。此处的关键字是校验，而正确的术语是“验证系统校验身份”。

　　验证可以提供保证，确保用户(或系统)是他们所说的身份。应用程序获取用户的凭据(各种形式的标识，如用户名和密码)并通过某些授权机构验证那些凭据。如果这些凭据有效，则提交这些凭据的实体被视为经过身份验证的标识。授权指用户访问网络资源的能力，通过对已验证身份授予或拒绝特定权限来限制访问权限。

　　验证可以直接在用户试图访问的计算机上执行，但在分布式环境中，用户帐户和安全信息通常由特殊的安全服务器存储和管理。当用户登录时，用户名和密码靠安全服务器进行校验。如果校验正确，密码将不会再通过电缆发送。用户密码保持秘密并从不通过网络是至关重要的，尤其是当密码为可读文本时，窃听者可以轻易捕获这些信息并使用它假装成该用户访问安全系统。相反，独特的握手式方案如此处所述以安全方式验证用户身份。

　　尽管单独的安全服务器提供许多好处(集中的安全和安全管理)，但在分布式环境中对用户进行身份验证呈现出许多有趣的挑战。

　　例如，假设某用户希望访问称为DOCS的安全服务器，当该用户登录时，其登录信息直接或间接地用于验证其身份。现在该用户试图访问DOCS服务器，假设DOCS“信任”该安全服务器，并假设它可正确地验证该用户。安全服务器已经验证了该用户的身份，因此DOCS也尝试验证该用户的身份就没有意。所需要的是“一次注册”验证方案，该方案可在无需进一步的登录请求的情况下使该用户访问信托网络环境中的任何系统，假设该用户具有整个网络的一个用户帐户。这可以按如下所示完成。

　　该用户的登录信息可以被缓存。当该用户访问另一台服务器时，该服务器获取登录信息，并用安全服务器校验登录信息。

　　当该用户第一次登录时，安全服务器可以发出登录凭证。该用户在登录会话的期间访问其他系统时将使用这些凭证。根据RFC l704 (On Internet Authentication， October 1994)释义，一个安全验证方案必须提供如下所示的“强相互验证”：

　　相互验证 交换中的双方使用可靠的方法了解对方身份的真实性。

　　强验证 双方都不获取可用于在另一会话中假冒对方的信息。

　　密码可用于相互验证，但不用于强验证。如果一方将其密码直接交给另一方，则会将有关自身的某些内容暴露出来，而其他系统可以使用这些信息冒充它。本质上，第一个“说话者”放弃了密码，并且变得易受攻击。窃听者也可以捕获密码并在以后使用(除非密码为一次性密码)。

　　强验证方案允许双方显示它们知道秘密而不展现实际秘密。再看前面的示例，假设某用户具有一个机密密码，他必须向安全服务器证明他知道密码，但不将密码通过网络传输。下面的四路握手方案是一个示例：

　　1、当该用户登录时，他的计算机生成随机数，并使用密钥对其加密。请注意，此密钥是从密码中导出的，或者是从本地加密文件获取的，而该加密文件只有在输入了正确的密码后才可访问。

　　2、结果发送到安全服务器，后者使用共享的密钥进行解密。

　　3、现在安全服务器具有该用户的服务器生成的随机数。它将该数字加1，然后生成自己的随机数，并用共享密钥为两者分别加密。

　　4、该用户的计算机接收该消息并解密。消息的第一部分应该是此计算机原来发送到安全服务器并加1的随机数，它证明此计算机与知道共享密钥的系统有联系。

　　5、下一步，该用户的计算机将从安全服务器接收的随机数加1，进行加密，然后将它返回到服务器。

　　6、当服务器接收此消息时，其随机数已经加1，服务器知道客户端一定是可信的。

　　经过验证后，客户端和服务器建立新密钥，在会话的剩余时间内该新密钥用于加密。这使登录密钥的使用变得最小。当然，共享的秘密必须保持秘密。如果有人获得它，这个人即可伪装成客户端或服务器。

　　经过这么多年，已经开发了许多验证协议和技术。CHAP(挑战握手验证协议)是一种加密的验证方式，能够避免建立连接时传送用户的真实密码。NAS向远程用户发送一个挑战口令，其中包括会话ID和一个任意生成的挑战字串。远程客户必须使用MD5单向哈希算法(one-way hashing algorithm)返回用户名和加密的挑战口令，会话ID以及用户口令，其中用户名以非哈希方式发送。

　　另一个协议是EAP(可扩展验证协议)。EAP是一种框架，支持可选择的多重PPP验证机制，包括纯文本密码，挑战-响应和任意对话顺序。

　　下面概述其他几种更先进的方案：

　　双因子验证 在此方法中，使用令牌设备(如智能卡)生成一个附加登录代码。此登录代码与服务器知道的代码在时间上同步。用户在登录时输入此代码、用户名及密码。因而需要两项才能登录：用户知道的某些内容(用户密码)以及用户具有的某些内容(令牌)。此方案要求所有用户都要有智能卡，并且此方案通常是为远程用户实现的。

　　Kerberos Kerberos是一个根据票证执行验证的制定得很好的协议。其命名是根据希腊神话中守卫冥王大门的长有三头的看门狗做的。定名是贴切的，因为Kerberos是一个三路处理方法，根据称为密匙分配中心(KDC)的第三方服务来验证计算机相互的身份，并建立密匙以保证计算机间安全连接。

　　票证是由称为KDC(密钥分发中心)的专用安全服务器发放的加密数据分组。KDC通常在企业网的内部进行维护，而企业网是KDC的授权区或管辖区。当用户登录时，由KDC处理验证。如果用户验证正确，则KDC向该用户颁发票证(称为“票证授权票”或TGT)。当此用户希望访问某个网络服务器时，KDC检查自己先前提供给用户的TGT(以校验票证依然可信)，然后向用户颁发服务票证，以允许用户访问目标服务器。目标服务器具有自己的校验票证以确认用户可信的方法，并根据预定义的访问控制授予用户访问权限。

　　Kerberos协议基本上是可行的，因为每台计算机分享KDC一个秘密，KDC有两个部件：一个Kerberos认证服务器和一个授票服务器。如果KDC不知请求的目标服务器，则求助于另一个KDC完成认证交易。Kerberos是一种网络认证协议，允许一台计算机通过交换加密消息在整个非安全网络上与另一台计算机互相证明身份。一旦身份得到验证，Kerberos协议给这两台计算机提供密匙，以进行安全通讯对话。Kerberos协议认证试图等录上网用户的身份，并通过使用密匙密码为用户间的通信加密。

　　证书、公钥和PKI(公共密钥基础结构) 如果要求安全登录到因特网服务器或其他公共服务器，则证书方案是适当的。证书基本上是数字ID，它受众所周知的证书颁发机构(如VeriSign)保护。它可以证明在连接另一端的人是其所说的身份。此方案使用公钥加密，并为用户提供一种方法，以向您提供其用于身份验证的公钥，以及在客户端和服务器之间加密会话。此方案与Kerberos的区别是Kerberos要求联机安全服务器对用户进行验证。证书是自包含的数据分组，其中包括对用户进行验证所需的所有内容。但是，它要求某实体颁发证书。这可以通过公共服务(如VeriSign)完成，可通过内部证书服务器完成(当公司希望颁发自己的证书给雇员时)。

　　圣杯一次注册

　　SSO(一次注册)的概念很简单。用户只需要一次键入其用户名和密码(第一次登录时)，以访问任何网络资源。在某些情况下，SSO甚至无需用户进一步提供证书即允许访问外部网络系统和因特网Web服务器。

　　Windows 2000网络通过使用Kerberos和Secure Sockets Layer (安全套接字层)协议可提高一次注册功能。这两种协议的优点是它们在混合网络环境中允许一次注册，而混合环境中的一些服务器可能是UNIX、Linux或也支持这两种协议的NetWare服务器。Microsoft SNA Server将SSO功能扩展到大型机环境。Microsoft声称Windows 2000是在异类网络中用作SSO集线器的最佳选择，原因是Windows 2000的SSO可以与其他供应商如此多的操作系统具有互操作性。在Windows 2000中，每个域控制器都是一个Kerberos密钥分发中心，该中心具有对应于该域的辖区。

　　SSL是由Netscape设计的一种开放协议;它指定了一种在应用程序协议(例如http、telnet、NNTP、FTP)和TCP/IP之间提供数据安全性分层的机制。它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证。SSL的主要目的是在两个通信应用程序之间提供私密信和可靠性。

　　任何SSO的一个重要特性是它可以附加到用作网络管理信息(包括用户帐户)的单个储备库的一些目录服务上。Novell NetWare和Microsoft Active Directory就是这样的目录服务。目录服务提供每个用户对整个网络中系统的权限和特权的一个权威性列表，这简化了管理和控制，并允许管理员在任何时候从单个位置更改登录特权和访问权限。

　　可以使用的SSO解决方案很多，在此将它们列出。

　　PassGo验证服务器 提供一次注册或单击访问公司企业网络上的所有资源，并有助于强化公司安全标准和规程。

　　Axent Technologies公司的企业安全管理器 企业安全管理器使得可以从单个位置自动化计划、管理和控制安全策略。

　　CyberSafe Trust Broker安全套件 这种套件的特点是多平台、一次注册验证，包括公钥和Kerberos加密。它保护一个组织的公司网和外部网免受内部和外部威胁。

　　Platinum Technologies公司的自动安全一次注册 AutoSecure SSO设计用于异类环境，包括大型机、分布式系统和PC。它不依赖于平台、应用程序、网络甚至其他安全机制。

　　ZOOMIT VIA 一个元目录服务，它使得设计、自定义和布署统一的企业目录服务变得容易。对于此讨论最重要的是，VIA对多个系统提供一次注册。

您正在使用哪些身份验证和授权方案 - 为啥？

【中文标题】您正在使用哪些身份验证和授权方案 - 为啥？

【英文标题】：Which authentication and authorization schemes are you using - and why?您正在使用哪些身份验证和授权方案 - 为什么？

【发布时间】：2010-10-19 22:30:13

【问题描述】：

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

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

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

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

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

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

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

感谢任何提示、指点、意见！

马克

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

【参考方案1】：

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

如果默认选项没有达到您的预期，您可以通过编写 membership、role 或 profile 提供程序来利用框架为您提供的许多工具和功能。喜欢。

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

---

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

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

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

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

【参考方案2】：

我们使用 (3)。实际上，这有助于我们在集成环境中与帐户同步

业务流程 其他系统（并非所有系统都在同一个技术堆栈 (ASP.NET) 上）

【参考方案3】：

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

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

【讨论】：

+1 表示 OpenID - 这是一个非常有趣的想法 - 谢谢！

【参考方案4】：

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

【讨论】：

那我们不是和 Active Directory 基本上在同一个地方吗？我们必须在 LDAP 中为 LDAP 中的任何用户（真实或虚拟）创建用户帐户，对吗？与其他选项相比，您认为有什么好处？

另外，据我了解（但如果我错了，请纠正我），LDAP 实际上只处理身份验证部分 - 你是谁？还是有一种简单的方法可以将授权也包含在内？ （作为用户你能做什么？）

ASP.NET 成员是否也提供了 AD 集成选项？例如，Ldap 允许数据源位于 Novell 或 Linux 系统上，而在这些系统上模拟 AD 将是一项艰巨的工作——即使可能 100% 匹配。

LDAP 向 Web 应用程序添加了另一个移动部分，如果您使用 AD LDAP 存储，则通过允许 Web 应用程序添加身份验证凭据，您将公司数据暴露在不必要的风险中可能在 Windows 网络上有效。

【参考方案5】：

不是 2003 年的 AZMan 吗？

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

【参考方案6】：

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

【讨论】：

我们一直在使用 AzMan。一路上遇到了一些问题，但没有什么无法解决的......

【参考方案7】：

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

【参考方案8】：

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

解决方案 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 

【讨论】：

真的吗？是否需要一个全面、完整且希望简单易用的解决方案来了解你是谁以及你可以成为什么？我认为这是这些天几乎 ANY 应用程序的基石，不是吗？

代码只是用户对象应该具有的基本属性的示例......您可以随时随地添加任意数量的...... +创建一些插件模型。我的观点是你必须有你自己的用户类（或者甚至从微软的一些用户类中派生出来，这取决于你为这些用户提供的服务..

这是一个如何从 MembershipUser 类派生的示例 - msdn.microsoft.com/en-us/library/ms366730.aspx