图6 {integrity}Sender的GSS-API实现
如果在调用GSS_GetMIC（）方法之前不存在可用的安全上下文，则Sender需要首先与Receiver之间建立安全上下文，通过安全机制信息的交互建立好安全上下文后可以继续调用GSS_GetMIC（）方法对需要发送的消息签名。
通信完整性抽象类Receiver用于对消息完整性进行检测，过程如图7所示。经过GSS_VerifyMIC（）方法检测接收到的消息及其签名是否一致以判定其完整性。如果没有合适的上下文可用，则应先建立安全上下文然后再调用GSS_VerifyMIC（）。
图7 {integrity}Receiver的GSS-API实现
如果需要实现的机密性保护，则Sender类和Receiver类的约束用{secrecy}表示。可通过GSS-API的GSS_Warp（）方法和GSS_Unwrap（）方法实现Sender和Receiver的安全功能。
Sender和Receiver还可以通过NGSS-API来实现。NGSS-API是ParlayAPI架构下的安全应用接口，对网络的安全能力进行抽象，并为业务提供安全能力。NGSS-API中提供了IpCredentialManager、IpContextManager、IpContext等类分别用于管理证书、管理安全上下文以及基于安全上下文的完整性、机密性等网络中的安全机制提供的安全能力。使用NGSS-API实现通信的完整性、机密性保护的过程与GSS-API类似。
GSS-API和NGSS-API都可用于实现根据业务安全需求抽象出的安全功能抽象类。GSS-API通常由本地的程序语言类库实现，适合于运行在终端和网络实体上的业务实例使用，保证本地与目的地交互的安全性。NGSS-API基于ParlayAPI，主要面向应用服务器等第三方业务实体，适合于运行在应用服务器上、与Parlay网关进行交互的业务实例使用，其安全需求通过Parlay网关协调网络中的实体实现，保证整体的安全性。GSS-API考虑的安全粒度是消息级的，而NGSS-API考虑的安全粒度相对要大一些，从应用服务器业务逻辑的视点出发，保证一个呼叫方或一个用户接口的安全性。
GSS-API和NGSS-API都独立于具体的安全机制，可以采用不同的安全机制和安全协议实现。
三、结语
本文根据NGN的网络特点对UMLsec进行了扩展，利用扩展后的UMLsec对NGN的网络环境和业务的安全需求进行了分析。将NGN业务的安全需求抽象成细粒度的安全能力抽象类，用UMLsec加以描述，通过这些类的组合完整表达NGN业务所需的安全特性。通过对安全能力抽象类的实现可以满足NGN业务的安全需求。本文通过用例说明了如何利用安全应用接口实现安全能力抽象类。基于安全应用接口的实现与具体安全机制的细节无关，且具有可移植性，使得业务的安全特性在不同的环境下可通过不同的安全机制实现。下一步的研究工作将包括对业务可用性等安全特征进行建模，并完善需求模型与实现模型之间的转换规则，以实现模型之间的自动转换与验证。
