文章插图
本文最初发布于devever.net网站,经原作者授权由InfoQ中文站翻译并分享 。
现在,身份验证协议的数量快赶上应用程序协议,结果,这个领域很容易让人困惑 。
最容易把人搞糊涂的是,很少有人注意到这样一种事实:
存在许多不同种类的身份验证协议,它们还试图扮演完全不同的角色 。与往常一样,首先请记住,身份验证和授权是不一样的功能 。考虑到这一点,本质上存在三种不同的身份验证协议类别:
- 客户端到应用程序(客户端身份验证协议)
- 应用程序到验证服务器(后端身份验证协议)
- 单点登录(客户端到验证服务器到多个应用程序)
应用程序到验证服务器的协议被应用程序服务器用来将客户端的身份验证委托给某个服务器,该客户端已使用客户端到应用程序的协议提供了信息,而验证服务器可以更好地执行身份验证决策 。这种协议允许将身份验证处理外包给专门的身份验证服务器,并且无需让身份验证数据库对所有应用程序服务器都开放访问权限 。
客户端的身份验证状态(例如通过客户端到应用程序的协议)通过单点登录服务器验证后,一台服务器使用单点登录协议与另一台服务器通信 。换句话说,它们被用来传递身份验证决策 。客户端先前成功通过验证服务器的身份验证的事实,可以在该客户端和应用程序服务器之间安全地传输 。某些协议不需要进一步干预或需要单点登录服务器可用,即可允许客户端在初始登录后对应用程序进行身份验证,而其他协议则需要 。
单点登录协议实际上包含两个协议:“客户端到验证服务器”部分和“客户端到应用程序”部分 。客户端到验证服务器部分可能是定制的,有时可能是非常普通的客户端到应用程序的身份验证协议 。而客户端到应用程序部分必须取决于SSO协议的设计 。
客户端到应用程序协议在客户端到应用程序验证协议的范畴内,存在验证框架和验证方法 。验证框架是一种可扩展的框架,它允许实施任意多种验证方法,并允许它在客户端和应用程序服务器之间动态协商使用哪种验证方法 。
一些身份验证框架已集成到特定的应用程序协议中 。还有一些通用设计旨在被集成到任意多个应用协议中 。这样甚至将来出现的应用程序协议也可以利用框架中已经定义的所有身份验证方法,以及这些方法的库实现 。
客户端到应用程序的身份验证框架:SASL这类框架中可能最流行的是IETF的SASL 。SASL没有定义特定的有线编码(这部分由应用程序负责),而是从本质上定义了身份验证方法名称(例如PLAIN、LOGIN、MD5等)的名称空间,以及协商它们的过程 。实际的方法特定协议已经执行,但是应用程序协议仅需要促成不透明二进制字符串序列的来回交换,直到身份验证成功或失败为止 。
简而言之,实现SASL的应用程序协议仅需要提供以下机制:
- 服务器将支持的方法名称(字符串)列表发送到客户端的一种途径
- 客户端发送其要使用的方法名称的途径
- 客户端将不透明的二进制字符串发送到选定的SASL方法的一种途径(可以由应用程序服务器不透明地输入到SASL库中)
- 服务器的SASL库将不透明的二进制字符串发送到客户端的一种途径(可以不透明地反馈回客户端的SASL库)
- 验证成功或失败的一种通信途径
一些最受欢迎的SASL方法是:
- PLAIN,以明文形式提供身份验证用户名和密码(以及可选的授权用户名,可能与身份验证用户名不同);
- LOGIN,弃用的方法,它是提供纯文本用户名和密码的另一种方法;
- EXTERNAL,使客户端完全不提供任何信息(可选的授权用户名除外),并且是客户端从连接上下文请求对其进行身份验证的一种方式 。例如,如果连接使用带有客户端证书的TLS,并且客户端证书足以满足身份验证的目的,则可以使用此方法进行身份验证;或者也能用于仅通过客户端IP地址对其进行身份验证的情况;
推荐阅读
- 根据判断PC浏览器类型和手机屏幕像素自动调用不同CSS
- 详解飞书新功能,如何让开发者“爽”起来?
- java中常见的六种线程池详解
- 如何挑选墨鱼
- 椰子没打开可以放多久?
- 翡翠手镯|翡翠不同的瑕疵造成的影响也不同,该怎样分辨?快来分辨不同属性
- 玻璃杯适合泡什么茶,泡不同的茶定要用不同的茶具吗
- linux网络编程常见API详解
- 详解三大编译器:gcc、llvm 和 clang
- 不同的场合该如何泡茶,如何泡茶