SSL 与 SASL
确实,SASL 不是协议而是抽象层。 SSL 和 SASL 也确实提供了类似的功能。它们都提供身份验证、数据签名和加密。
SSL 在传输层完成,它通常对底层协议是透明的。例如,您可以在 LDAP 或 HTTP 上使用 SSL。但是,在某些情况下,需要修改现有协议才能切换到安全模式。例如,POP3 和 IMAP 扩展为具有命令STARTTLS 来启动 SSL 的使用。从这个角度来看,这有点类似于 SASL 的做法。
另一方面,许多协议也被扩展以提供 SASL 功能。 Here 是协议列表。同样,POP3 和 IMAP 是其中的两个,它们使用不同的命令来启动身份验证。
那么,我们什么时候应该使用 SSL,什么时候应该使用 SASL?
SSL 和 SASL 之间的一个明显区别是 SASL 允许您选择不同的机制来验证客户端,而 SSL 是一种绑定以基于证书进行身份验证。在SASL中,可以选择使用GSSAPI、Kerberos、NTLM等。
由于这种差异,在某些情况下,使用 SASL 而不是 SSL 更直观。例如,您的客户端应用程序正在使用 Kerberos 对最终用户进行身份验证。您的服务器需要对客户端进行身份验证。由于您的客户端应用程序已经具有 Kerberos 凭据(在 Kerberos 术语中,票证),因此使用 Kerberos 凭据向服务器进行身份验证是有意义的。当然,您始终可以设置 SSL 来做同样的事情。但是,这意味着在现有 Kerberos 基础设施之上,您需要设置证书颁发机构基础设施,并以某种方式将客户端证书与 Kerberos 凭据相关联。这是可行的,但工作量很大。
此外,有时,您需要使用一些仅在 SASL 机制中可用但在 SSL 中不可用的功能。例如,Kerberos 允许您将票据从客户端转发到服务器,以便服务器可以使用票据代表客户端查询一些资源。一个常见的例子是你有一个应用服务器和一个数据库。客户端应用程序向应用程序服务器进行身份验证,并且应用程序服务器需要使用客户端的凭据代表客户端查询数据库。 SSL 无法为您提供此功能,但 Kerberos 支持此功能。因此,在这种情况下,您必须选择使用 SASL。
在某些情况下,您确实想使用 SSL 而不是 SASL。例如,扩展协议不是一种选择,或者您想加密使用底层协议交换的每个数据包。
GSSAPI 与 Kerberos 和 SASL 有何关系
根据wiki page,SASL 中支持 GSSAPI 和 Kerberos 机制。 GSSAPI 是一个通用的编程接口。这个想法是让应用程序编写者使用一个通用 API 来进行身份验证、加密等,而不管下面使用什么协议。 GSSAPI 实现 Kerberos。因此,您可以使用 GSSAPI 进行 Kerberos 身份验证。
JAAS 与 SASL 有何关系
说实话,我不是 Java 专家。根据我的阅读,听起来 JAAS 只是一个可插入的身份验证框架。我相信这个想法类似于 GSSAPI。无论使用什么身份验证方法,它都提供一个单一的编程接口。 GSSAPI 专注于身份验证和安全消息交换,而 JAAS 专注于身份验证和授权。我没有找到任何证据表明 JAAS 也是 SASL 机制之一。我相信 Java 库中应该有一些帮助类可以帮助您实现自定义 SASL 机制。在实现自定义 SASL 机制时,只使用 JAAS 可能是有意义的。