Sender类和Receiver类是通过对通信安全功能的抽象而得出的两个类。这两个类具备保证发送方和接收方之间消息传送的完整性的安全能力。通过在UA的信令控制功能和Proxy的呼叫控制功能中聚合这两个类，可以在高层的需求层面上满足UA和Proxy通信的信令完整性需求。
AccessGuard类是用于隔离对保护对象的访问的类，通过在被保护对象上标识{guard=AccessGuard}标记，所有的对保护对象的访问请求需先提交给AccessGuard类，AccessGuard类根据具体的访问控制机制和访问控制策略进行访问权限的判定后，访问请求才能在被保护对象上执行。
Sender类和Receiver类可以针对业务对安全需求的不同控制粒度进一步细化，通过对send（）方法的重载加以实现。如在调用send（）方法时可以使用QoP[5，7]（QualityofProtection）参数说明业务对安全功能的保护级别的需求。QoP体现了处理安全问题的开销与安全保护需求之间的动态平衡。某一级别的QoP可以对应于某一具体安全机制中所采用的加密算法强度、密钥长度、认证机制强度等。但目前QoP的定义还依赖于具体的安全机制，且具有一定的随意性，没有一个客观的标准。
在更细的粒度上，用户可以在send（）方法中指定具体安全机制的相关参数，对所使用的安全机制进行更精确的控制。
图5是对通信机密性进行保护的安全能力抽象类的类图。其send（）方法应能保证消息的加密传输。Receiver类的receive（）方法用于接收并解密消息。同完整性保护一样，更加细致和更加可控的机密性保护可通过对send（）和receive（）方法的重载实现。
除了图4和图5中列举的用于保护通信完整性和机密性以及实体访问控制的安全能力抽象类外，还可以根据业务的实际安全需求抽象更多的安全能力抽象类。每个类实现某一特定的安全功能，如可以在多媒体会议中定义群密钥管理功能抽象类，用于满足群密钥生成、分发与认证的功能。
图4 安全功能抽象类图示例
图5 消息机密性安全功能类
二、业务安全的实现机制
基于上述分析，可以将NGN业务的安全需求从安全特性上加以划分并进行抽象，形成一系列细粒度的安全功能抽象类。通过对每一个安全功能抽象类的实现可以满足业务的安全需求。文献[8]提出了一种基于模型驱动的细粒度的访问控制框架AC-PIM，将一个统一的高层的访问控制模型（AC-PIM）映射到多种具体的访问控制机制中，如OASIS的SAML（SecurityAssertionMarkupLanguage）和XACML（eXtensible Access Control Markup Language），OMG的RAD（Resource Access Decision Facility）以及Java Authentication and Authorization中定义的Java访问控制模型。AC-PIM提供了一个实现图4中的AccessGuard抽象类的途径。
下面说明如何利用GSS-API实现保证通信完整性的安全能力抽象类，通过状态图说明保证通信完整性的Sender类的send（）方法及Receiver类的receive（）方法的GSS-API实现。本文中给出的是一个示意性的说明，忽略了一些错误处理过程。
图6中，在send（）方法被调用后，Sender首先检测是否已有可用的安全上下文，如果可用的安全上下文已经存在，则可以利用该上下文的句柄作为参数之一，调用GSS-API的Get_GetMIC（）方法。参数还包括有待进行签名的消息和可选的QoP。如果对消息签名可以正常完成，Sender就可以将消息与签名后生成的token一起送到目的地。如果签名发生异常，则可以通过返回的错误码判断原因。
