详解三种不同的身份验证协议


详解三种不同的身份验证协议

文章插图
 
本文最初发布于devever.net网站,经原作者授权由InfoQ中文站翻译并分享 。
现在,身份验证协议的数量快赶上应用程序协议,结果,这个领域很容易让人困惑 。
最容易把人搞糊涂的是,很少有人注意到这样一种事实:
存在许多不同种类的身份验证协议,它们还试图扮演完全不同的角色 。
与往常一样,首先请记住,身份验证和授权是不一样的功能 。考虑到这一点,本质上存在三种不同的身份验证协议类别:
  • 客户端到应用程序(客户端身份验证协议)
  • 应用程序到验证服务器(后端身份验证协议)
  • 单点登录(客户端到验证服务器到多个应用程序)
客户端到应用程序的身份验证协议由客户端发送给应用程序服务器进行身份验证 。这种协议完全不揭示应用程序服务器在幕后如何使用客户端提供的信息对其进行身份验证 。
应用程序到验证服务器的协议被应用程序服务器用来将客户端的身份验证委托给某个服务器,该客户端已使用客户端到应用程序的协议提供了信息,而验证服务器可以更好地执行身份验证决策 。这种协议允许将身份验证处理外包给专门的身份验证服务器,并且无需让身份验证数据库对所有应用程序服务器都开放访问权限 。
客户端的身份验证状态(例如通过客户端到应用程序的协议)通过单点登录服务器验证后,一台服务器使用单点登录协议与另一台服务器通信 。换句话说,它们被用来传递身份验证决策 。客户端先前成功通过验证服务器的身份验证的事实,可以在该客户端和应用程序服务器之间安全地传输 。某些协议不需要进一步干预或需要单点登录服务器可用,即可允许客户端在初始登录后对应用程序进行身份验证,而其他协议则需要 。
单点登录协议实际上包含两个协议:“客户端到验证服务器”部分和“客户端到应用程序”部分 。客户端到验证服务器部分可能是定制的,有时可能是非常普通的客户端到应用程序的身份验证协议 。而客户端到应用程序部分必须取决于SSO协议的设计 。
客户端到应用程序协议在客户端到应用程序验证协议的范畴内,存在验证框架和验证方法 。验证框架是一种可扩展的框架,它允许实施任意多种验证方法,并允许它在客户端和应用程序服务器之间动态协商使用哪种验证方法 。
一些身份验证框架已集成到特定的应用程序协议中 。还有一些通用设计旨在被集成到任意多个应用协议中 。这样甚至将来出现的应用程序协议也可以利用框架中已经定义的所有身份验证方法,以及这些方法的库实现 。
客户端到应用程序的身份验证框架:SASL这类框架中可能最流行的是IETF的SASL 。SASL没有定义特定的有线编码(这部分由应用程序负责),而是从本质上定义了身份验证方法名称(例如PLAIN、LOGIN、MD5等)的名称空间,以及协商它们的过程 。实际的方法特定协议已经执行,但是应用程序协议仅需要促成不透明二进制字符串序列的来回交换,直到身份验证成功或失败为止 。
简而言之,实现SASL的应用程序协议仅需要提供以下机制:
  • 服务器将支持的方法名称(字符串)列表发送到客户端的一种途径
  • 客户端发送其要使用的方法名称的途径
  • 客户端将不透明的二进制字符串发送到选定的SASL方法的一种途径(可以由应用程序服务器不透明地输入到SASL库中)
  • 服务器的SASL库将不透明的二进制字符串发送到客户端的一种途径(可以不透明地反馈回客户端的SASL库)
  • 验证成功或失败的一种通信途径
如何提供这些机制取决于应用程序协议,该协议必须定义一些适当的有线协议 。尽管特定的编组和状态机是特定于应用程序协议的,但是SASL方法本身就足够独立于应用程序协议,因此实现各种SASL方法的通用SASL库被广泛采用 。
一些最受欢迎的SASL方法是: