GSSAPI 编程交互过程

通过一个简单的编程模型,解释通过JGSS API 进行编程的通用交互过程。客户端应用程序将数据发送到远程服务器并且通过认证,过程如下:

  1. 应用程序,无论是发送端还是接受端,如果尚未自动获取安全凭据(credential),则需明确获取安全凭据;
  • 发送端初始化安全上下文Security Context,接受端接受该安全上下文;
  • 发送端对其要传输的消息应用安全保护(Security Protection),比如加密消息或消息完整性保护。发送端发送受保护的消息;发送端也可选择不应用任何安全保护,在这种情况下,消息发送端和接收端只应用默认的GSS-API安全服务,即身份验证,其中接收端知道发送端是其声称的一方;
  • 接收端解密消息,如果需要,则验证消息;
  • 可选的一步是:接收端向发送端返回识别标签以进行身份确认;
  • 会话结束后,发送端和接收端应用程序销毁共享安全上下文对象(Security Context),如有必要,清除敏感GSS-API数据;

安全上下文建立阶段(Security Context)

数据加密传输阶段

主要概念介绍

安全凭证(Credentials)

安全凭证是一种数据结构,用于提供应用程序声明主体的证据。应用程序使用凭证来作为其身份标识。安全凭证可以是一组信息,证明某人,组织或服务是其声称的实体。需要注意的是,GSS-API本身不提供凭据,在调用GSS-API函数之前,凭据是由GSS-API底层的安全机制创建的。如对Kerberos 安全机制为例,需要创建User Principal 和SPN (Service Principal Name);

安全上下文(Security Context)

Security Context可以被认为是应用程序之间的一种“信任状态”。共享Security Context的应用程序信任彼此,只要Security Context持续,应用程序之间的数据就可以安全传输;使用获取的凭证可以在应用程序之间建立安全上下文。GSS-API以独立于底层传输协议的方式运行,应用程序负责传输由安全上下文(Security Context)生成的令牌;

安全上下文建立(Context Establishment)

GSS-API在提供安全性方面所做的两件最重要的事情是创建安全上下文和保护数据。在应用程序具有所需的凭据后,就可以开始建立安全上下文。通常情况下,发送端应用程序(通常是客户端)启动上下文,接收端应用程序(通常是服务端)接受该上下文。注意,允许在应用程序之间存在多个上下文;应用程序通过交换认证令牌来建立共享的安全上下文。安全上下文也可认为是一对GSS-API数据结构,包含两个应用程序之间共享的安全信息,这些安全信息描述了每个应用程序的安全状态以及保护数据所需要的安全信息;

数据保护质量QOP (Quality-of-Protection)

GSSAPI交互中,需指定所需的QOP(保护质量),来指定是否需要消息加密。QOP值指定要使用的加密完整性和加密算法。对应于各种QOP值的算法由底层安全机制的提供者指定,通常将0指定为QOP默认值;

GSSAPI 编程交互过程