16、GAA部署指南：应用服务器集成与安全访问控制

GAA部署指南：应用服务器集成与安全访问控制

1. 与应用服务器集成

为了让应用服务器能够使用通用认证架构（GAA）对用户进行认证，并确保终端与应用服务器之间的通信安全，应用服务器需要具备GAA感知能力。这意味着应用服务器必须包含网络应用功能（NAF），以便能够从引导安全功能（BSF）请求GAA参数，并处理终端与服务器之间的通信以利用这些参数。

实现这一目标有两种不同的机制：
- 使用现成的、完全可配置的NAF库，该库嵌入了NAF与BSF之间所有必要且可能复杂的通信机制，并提供处理来自用户设备（UE）请求的通用实用功能。
- 使用基于Web服务的Zn接口的Web服务描述语言（WSDL）描述来生成NAF所需的所有骨架代码，此时NAF只是一个Web服务客户端或消费者。

此外，还可以透明地为应用服务器添加GAA感知能力。在这种情况下，应用服务器本身无需修改，而是可以修改认证服务器以支持基于GAA的凭证，或者在应用服务器和认证服务器之间引入代理来处理基于GAA的认证。

1.1 用户名/密码替换

目前，互联网上的大多数应用服务器基于用户名/密码方案进行最终用户认证。用户通常在专用应用程序或网页浏览器的HTML表单中输入用户名和密码，这些凭证数据通过各种方式（如使用服务器认证的SSL或TLS隧道保护的HTTP，即HTTPS）传输到应用服务器。

为了在这种场景中启用基于GAA的认证，客户端应用程序必须具备GAA感知能力，并使用B-TID作为用户名，应用特定的GAA密钥（Ks_NAF）作为密码。具体来说，客户端应用程序应能够识别何时需要基于GAA的凭证，从GAA模块获取凭证并将其插入正确的上下文。对于网页浏览器和HTML表单，可能需要增强JavaScript以实现这些功能。

对于现有的应用服务器，有两种适应方法：
- 直接修改应用服务器以支持GAA。
- 调整密码验证过程以支持基于GAA的凭证。

下面详细介绍引入代理的方法：
1. 代理功能 ：开发者可以在应用服务器和认证服务器之间引入代理功能。该代理将拦截来自应用服务器的所有认证请求，如果是基于GAA的凭证，则在本地处理；如果是普通的用户名/密码，则将认证请求转发到认证服务器。
2. GAA凭证处理 ：如果凭证是基于GAA的，代理将使用认证请求用户名字段中的B-TID，并从BSF获取Ks_NAF和用户安全设置（USS）。然后，它将检查密码字段中的Ks_NAF是否与从BSF收到的Ks_NAF相同。如果认证请求包含对挑战的响应，代理将使用Ks_NAF验证响应。
3. 数据库接口调整 ：由于应用服务器可能需要访问其本地数据库中的用户特定数据，因此可能需要更改该数据库的接口，以便将BSF返回的用户身份B-TID作为访问数据的键。这样，应用服务器可以使用它认为是用户名的B-TID正常获取用户数据。

这种方法的优点是正常的用户名/密码方案可以与基于GAA的方案并存，同一最终用户可以在移动电话上使用基于GAA的认证，在PC上使用基于用户名/密码的认证。

1.2 NAF库

NAF库有多种形式，其目的是简化NAF应用服务器逻辑的开发，特别是减少专门用于GAA特定功能的代码行数。在理想情况下，所有更改都在配置文件中完成，无需编写任何GAA特定的代码。目前，虽然没有通用的NAF库工具公开可用，但BSF供应商很可能会为应用服务器开发者提供工具，以方便利用GAA基础设施。

以下是一些使用现有应用服务器实现NAF功能和NAF库集成的示例：
- Apache Web服务器 ：引入支持GAA的Apache Web服务器的最直接方法是增强常用的Apache认证模块mod_auth，以支持基于GAA的认证。由于mod_auth已经支持HTTP Digest，因此相对容易添加对基于GAA的HTTP Digest挑战和请求的识别和处理支持。当认证模块具备此支持后，可以通过编辑相应的配置文件（如httpd.conf或.htaccess文件）来启用它。应用服务器逻辑可以通过环境变量获取经过认证的GAA身份。

示例.htaccess文件内容如下：

# GAA authentication module settings
AuthType GAADigest
AuthName “3gpp-bootstrapping@example.server.com”
BSFAddress “bsf.operator.com”
BSFConnType WebService
BSFGSIDSet 1,9999

• J2EE服务器 ：Java 2 Enterprise Edition（J2EE）可以将基于GAA的认证嵌入到处理传入请求的过滤器中。原理与Apache Web服务器类似，其中GAADigestAuthenticationFilter作为NAF库的一部分实现。GAA过滤器在相应J2EE应用的web.xml文件中配置。

示例web.xml文件内容如下：

<!-- GAA authentication filter -->
<filter> 
    <filter-name>GAAFilter</filter-name>
    <filter-class>com.nokia.gaa.filter.GAADigestAuthenticationFilter</filter-class>
    <init-param>
        <!-- put here the URL to the  BSF -->
        <param-name>bsfURL</param-name>
        <param-value>http://bsf.operator.com:5320/</param-value>
    </init-param>
</filter>
<filter-mapping> 
    <!-- put here the url-pattern for which GAA authentication will be used -->
    <filter-name>GAAFilter</filter-name>
    <url-pattern>/gaa-protected/*</url-pattern>
</filter-mapping>

• 直接使用NAF库 ：NAF库也可以直接使用，因为它提供了丰富的API来与基于GAA的参数和函数进行交互。以下是一个直接使用NAF库API的Java代码示例：

// import the package
import com.nokia.research.gaa.*;
// class definitions, etc. in here.
// Get B-TID from incoming request
String btid = request.getParameter(“btid”);
// Initialize the connection to BSF  
GAAConnection c = GAAFactory.getGAAConnection(
    “com.nokia.gaa.internal.SOAPConnection”,
    “http://bsf.operator.com:9999/”);
// Create the request, happens typically when
// UE has contacted NAF and given B-TID  
GAARequest req = 
    GAAFactory.getGAARequest(btid,”example.server.com”);
// Add one GSID to request certain USS
req.addAid(“123”);
// Send the query to BSF
GAAResponse resp = c.send(req);
// Get persistent user identity (this would be the IMPI):
String uid = resp.getUid();
// Get the ME key (normal GAA):
byte[] key = resp.getMEKey();
// use the key as it is (e.g., in HTTP Digest as password)
// Get application specific USS (if not found this
// returns null):
USS uss = resp.getUSS(“123”);
// Test if it contains an authorized UID allowed by access
// control policy (uid, which is fetched from local policy
// system of the NAF).
if (uss.containsUid(uid)) {
    // yes it does
}
// any additional service logic follows

1.3 Web服务直接使用

与任何基于Web服务的开发工具一样，应用开发者也可以通过使用Zn接口的WSDL定义文件来生成基本的NAF功能。该定义文件在相关文档中定义，可以在任何基于Web服务的工具中使用，以生成访问BSF的客户端骨架代码。在这种情况下，开发者还必须实现所有其他支持功能，因为WSDL仅描述接口本身。这种方法适用于没有现成NAF库可用的情况，例如应用服务器使用支持Web服务但尚未实现NAF库的编程语言。

2. 与操作系统安全集成

在UE端实现GAA时，会涉及到一些安全问题，需要通过访问控制来解决。

2.1 开放平台UE中GAA实现的威胁

UE端GAA实现的典型软件架构包含两个可能需要访问控制的接口：一个是与通用集成电路卡（UICC）的接口（通过设备驱动程序），另一个是与BSF客户端（也称为GBA模块）的接口。

在封闭平台中，UE上的所有软件模块都是预安装的，可以被视为可信的，因此访问控制不是问题。然而，开放平台的固有特性是可以在UE上安装新的应用程序，这会带来以下威胁：
- 接口1 ：恶意应用程序可以直接访问UICC，从而充当BSF客户端，与UICC和BSF进行通信，建立GAA主会话密钥。
- 接口2 ：恶意应用程序可以访问BSF客户端API，从中获取特定于NAF的GAA会话密钥。

恶意应用程序可以将窃取的秘密（GAA主会话密钥或一个或多个特定于NAF的GAA会话密钥）发送给网络中的同伙。攻击者可以冒充NAF向UE发起攻击，或者冒充UE向NAF发起攻击，这两种情况都可能导致私人数据丢失或服务被未经授权使用。

假设UE平台提供内存保护，将进程的运行时内存相互隔离。如果平台为应用程序提供私有存储（如Symbian OS），BSF客户端或NAF客户端可以持久存储各自的秘密；否则，秘密只能保存在运行时内存中。

下面是UE端GAA软件架构的简单mermaid流程图：

graph LR
    A[User Equipment] -->|Interface 1| B[UICC device driver]
    B --> C[UICC]
    A -->|Interface 2| D[BSF Client (GBA module)]
    D -->|Zn| E[BSF]
    A -->|Ua| F[NAF client (an application using GAA)]
    F -->|Ua| G[NAF]

2.2 访问控制要求

可以通过在相应接口上指定和实施访问控制来解决上述两种威胁：
- 对于接口1的威胁，可以通过仅允许授权的BSF客户端访问UICC来解决。
- 对于接口2的威胁，可以通过限制对GAA服务器API的访问，仅允许授权的应用程序使用来解决。

在实施对接口2的访问控制时，需要考虑两个问题：访问控制策略的设置和访问控制的粒度。
- 粒度 ：最简单的方法是将应用程序分为两类：授权应用程序允许使用BSF客户端API，未授权应用程序则不允许。授权应用程序可以获取任何NAF的特定于NAF的会话密钥，这是粗粒度的访问控制。另一种选择是限制特定应用程序，使其只能获取一部分NAF或应用协议的特定于NAF的会话密钥，这是细粒度的访问控制。
- 策略设置 ：在任何一种访问控制类型中，策略可以由设备制造商、网络运营商、第三方（如企业中的系统管理员）或用户自己设置。

粗粒度的访问控制方法对于由UE制造商或运营商授权的应用程序来说已经足够。然而，如果UE允许用户或第三方授权应用程序，可能需要细粒度的访问控制，因为用户可能仅仅因为应用程序请求就授予授权，而第三方授权者可能彼此之间或与制造商/运营商之间缺乏信任。例如，运营商可以指定一组敏感的NAF，只有运营商授权的应用程序才能获取这些NAF的特定于NAF的密钥。用户授权的应用程序可以获取任何非运营商策略中分类为敏感的NAF的特定于NAF的密钥。

在实践中，访问控制实现有两个级别：
- 基本级别 ：仅支持粗粒度的访问控制，用户不允许授权应用程序或设置策略。对于许多场景和应用程序来说，这种基本的访问控制已经足够。
- 扩展级别 ：允许用户授权应用程序，并支持更细粒度的访问控制。访问控制策略可以指定为包含列表（如“应用程序ABC被允许请求标识符匹配模式x.y.z的NAF的特定于NAF的密钥”）或排除列表（如“只有应用程序ABC被允许请求x.y.z的特定于NAF的密钥”）。

2.3 实践中的基本访问控制：Series 60平台集成

Series 60平台的3.0版本（及更高版本）基于Symbian OS 9.0，该系统包含平台安全功能。在了解GAA在Series 60平台上的实现如何利用它之前，先简要介绍Symbian OS平台安全的基本特征。

在Symbian Series 60 3.0（及以上版本）中，所有要安装的应用程序必须进行数字签名，未签名的应用程序无法安装。应用程序主要分为两类：
- 可信应用程序 ：由可信签名者签名，其证书可以验证到设备中的可信根证书。
- 不可信应用程序 ：由不可信签名者签名，其证书无法验证。

Symbian平台安全的运行时访问控制基于能力（capabilities）。能力是访问资源的权限表示，每个进程都有一组与之关联的能力。在Symbian OS中，资源由服务器进程保护，当一个进程请求访问服务器进程中的资源时，服务器进程会检查请求进程是否具备访问该资源所需的能力。

能力在应用程序安装时授予。每个软件包列出其正确执行所需的能力，只有当应用程序安装程序决定授予所有请求的能力时，安装才能成功。如果应用程序是可信的，并且请求的能力是签名者证书和从签名者证书到可信根证书的认证路径中证书所列元能力的子集，那么应用程序安装程序将授予请求的能力。如果应用程序是不可信的，并且请求的能力属于用户可授予的能力子集，安装程序可能会询问用户是否授予请求的能力。

在Series 60平台中，BSF客户端是一个Symbian OS服务器，称为“GAA服务器”或“GBA模块”。NAF客户端可以通过使用GAA客户端库访问GAA服务器。

接口1的访问控制由UICC“设备驱动程序”执行（这里的“设备驱动程序”是一个宽泛的术语，根据Series 60平台与硬件架构的集成方式，GAA服务器与UICC之间的通信可能会经过多个软件模块）。为了最终访问UICC，GAA服务器需要ReadDeviceData和WriteDeviceData能力，还需要NetworkServices能力才能通过网络接口与BSF进行通信。

以下是一个简单的表格总结了GAA服务器访问UICC和与BSF通信所需的能力：
| 操作 | 所需能力 |
| ---- | ---- |
| 访问UICC | ReadDeviceData, WriteDeviceData |
| 与BSF通信 | NetworkServices |

通过以上的访问控制措施，可以有效提高UE端GAA实现的安全性，保护用户的隐私和服务的正常使用。

GAA部署指南：应用服务器集成与安全访问控制

3. 访问控制策略的实际应用与效果分析

在实际应用中，不同级别的访问控制策略对GAA系统的安全性和可用性有着不同的影响。

3.1 基本级别访问控制的应用场景与效果

基本级别仅支持粗粒度的访问控制，用户不允许授权应用程序或设置策略。这种访问控制适用于对安全性要求相对较低、应用程序来源较为单一且受信任的场景。

例如，在一些企业内部的封闭网络环境中，所有应用程序都由企业统一部署和管理，此时采用基本级别访问控制可以确保只有经过企业认可的应用程序能够访问GAA相关资源。这种方式的优点在于管理简单，减少了因用户随意授权应用程序而带来的安全风险。

以下是基本级别访问控制的效果分析表格：
| 优点 | 缺点 |
| ---- | ---- |
| 管理简单，减少安全配置的复杂性 | 缺乏灵活性，无法满足多样化的应用需求 |
| 降低用户误操作或恶意授权带来的风险 | 对于新业务或特殊应用场景支持不足 |

3.2 扩展级别访问控制的应用场景与效果

扩展级别允许用户授权应用程序，并支持更细粒度的访问控制。这种访问控制适用于开放性较高、应用程序来源广泛的场景，如移动互联网应用市场。

在移动互联网环境中，用户可以自由下载和安装各种应用程序，不同应用程序对GAA资源的访问需求也各不相同。通过细粒度的访问控制，运营商可以指定敏感的NAF，只有特定授权的应用程序才能访问这些资源，从而在保证用户体验的同时，有效保护敏感信息。

以下是扩展级别访问控制的效果分析表格：
| 优点 | 缺点 |
| ---- | ---- |
| 灵活性高，能够满足多样化的应用需求 | 管理复杂，增加了安全配置的难度 |
| 更好地保护敏感信息，提高系统安全性 | 用户可能因不了解授权风险而做出错误决策 |

4. 不同应用服务器集成GAA的对比与选择

不同类型的应用服务器在集成GAA时，具有不同的特点和适用场景。

4.1 不同应用服务器集成GAA的特点对比

应用服务器类型	集成方式	优点	缺点
Apache Web服务器	增强mod_auth模块	集成相对简单，利用现有模块功能	可能需要对配置文件有一定了解
J2EE服务器	嵌入过滤器	与Java生态系统集成良好，便于开发	对Java开发环境有依赖
直接使用NAF库	调用API	灵活性高，可定制性强	开发难度较大，需要对GAA有深入理解
Web服务直接使用	基于WSDL生成代码	适用于无现成NAF库的情况	需要实现额外支持功能

4.2 选择建议

在选择应用服务器集成GAA的方式时，需要考虑以下因素：
- 开发团队技术栈 ：如果开发团队熟悉Java开发，J2EE服务器集成方式可能更合适；如果对Web服务开发有经验，Web服务直接使用方式可能是一个选择。
- 应用场景复杂度 ：对于简单的应用场景，使用Apache Web服务器增强模块的方式可能足够；对于复杂的应用场景，可能需要直接使用NAF库来实现定制化需求。
- 现有资源情况 ：如果已经有现成的Web服务开发工具和环境，使用WSDL生成代码的方式可以节省开发成本。

以下是选择应用服务器集成GAA方式的mermaid流程图：

graph LR
    A[确定开发团队技术栈] -->|Java熟悉| B[考虑J2EE服务器集成]
    A -->|Web服务经验| C[考虑Web服务直接使用]
    A -->|其他| D[综合考虑其他方式]
    E[确定应用场景复杂度] -->|简单| F[考虑Apache Web服务器集成]
    E -->|复杂| G[考虑直接使用NAF库]
    H[确定现有资源情况] -->|有Web服务工具| C
    H -->|无Web服务工具| D

5. GAA部署的最佳实践总结

为了确保GAA部署的顺利进行和系统的安全性，以下是一些最佳实践建议：
1. 安全策略制定 ：根据应用场景和安全需求，合理选择基本级别或扩展级别访问控制策略。对于敏感信息和关键业务，采用细粒度的访问控制。
2. 应用服务器集成 ：根据开发团队技术栈、应用场景复杂度和现有资源情况，选择合适的应用服务器集成方式。在集成过程中，严格按照相关配置文件的要求进行设置。
3. 用户教育 ：在支持用户授权应用程序的情况下，加强用户教育，提高用户对授权风险的认识，避免因误操作而带来安全隐患。
4. 定期审计 ：定期对GAA系统进行安全审计，检查访问控制策略的执行情况，及时发现和处理潜在的安全问题。

通过遵循以上最佳实践，可以有效提高GAA系统的安全性和可用性，为用户提供更加可靠的服务。

综上所述，GAA部署涉及到应用服务器集成和操作系统安全集成等多个方面，需要综合考虑各种因素，选择合适的技术和策略，以确保系统的安全稳定运行。在实际应用中，不断总结经验，优化部署方案，才能更好地适应不断变化的业务需求和安全挑战。