17、GAA部署指南：从访问控制到网络集成

最新推荐文章于 2025-11-19 01:02:58 发布

吃瓜不吐籽595

最新推荐文章于 2025-11-19 01:02:58 发布

阅读量15

点赞数

CC 4.0 BY-SA版权

分类专栏：蜂窝认证：连接移动与互联网文章标签： GAA 访问控制身份管理系统

本文链接：https://blog.youkuaiyun.com/oauth7security/article/details/154172530

蜂窝认证：连接移动与互联网专栏收录该内容

19 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

GAA部署指南：从访问控制到网络集成

在当今数字化时代，移动和互联网服务的安全性至关重要。GAA（Generic Authentication Architecture）作为一种通用认证架构，为移动和互联网服务的认证提供了有效的解决方案。本文将深入探讨GAA的部署相关内容，包括访问控制、与身份管理系统的集成以及与移动网络的集成等方面。

1. GAA访问控制

在GAA的部署中，访问控制是保障系统安全的重要环节。

1.1 基本访问控制

在图5.3所示的架构中，接口2的访问控制由GAA服务器进行管理。NAF客户端若要访问特定于NAF的机密信息，至少需要具备Read - DeviceData能力。对于一些更关键的NAF特定密钥，如3GPP MBMS和OMA BCAST智能卡配置文件密钥，GAA服务器可能会要求比ReadDeviceData更高的能力，如NetworkControl能力，该能力通常只有设备制造商才能授予。

此外，如果NAF客户端指定要从BSF进行引导的地址，则还需要WriteDeviceData能力。大多数NAF客户端通常还需要NetworkAccess能力来打开与NAF的网络连接。

1.2 扩展访问控制设计选项

为了实现更精细的访问控制，可以采用以下方法：
- 安全标识符（SID）和供应商标识符（VID） ：每个Symbian OS应用程序由安全标识符（SID）标识，SID是本地唯一的标识符。如果SID处于受保护范围（低于0x7FFFFFFF），则可以对应用程序进行身份验证，因为处于该范围的应用程序必须由可信签名者签名。供应商标识符（VID）用于识别应用程序的供应商，非零VID的应用程序也必须由可信签名者签名。SID和VID可用于细粒度访问控制，将应用程序映射到特定策略，决定其是否可以访问特定于NAF的密钥。
- 访问控制列表（ACL） ：为了让UE制造商或运营商能够在UE中配置细粒度访问控制，限制对敏感NAF标识符的访问，GAA服务器必须包含访问控制列表（ACL）。ACL保护的资源是特定于NAF的密钥，可使用正则表达式在NAF标识符上进行识别。ACL中的主体是应用程序标识符，在Symbian OS中可以是SID或VID。设备管理（DM）系统，如OMA DM，可用于配置和更新GAA服务器的ACL。
- 用户授权查询 ：用户查询类似于个人防火墙功能，用户会被提示是否允许某个应用程序打开或接受网络连接。在基于Symbian OS的UE上，用户授权查询可用于约束已经具备ReadUserData能力的应用程序。在其他平台上，可用于允许原本不可信的应用程序访问选定的特定于NAF的会话密钥。用户提示应显示请求访问GAA服务器的应用程序名称和请求GAA会话密钥的NAF地址，用户可以选择授予或拒绝访问，还可以选择是否记住该决定，以便下次相同应用程序请求相同NAF的GAA会话密钥时自动授予访问权限，这可以在GAA服务器中实现为特定于用户的ACL。

2. 其他平台的访问控制实现

除了Symbian OS平台，其他平台也可以实现类似的访问控制。实现访问控制通常需要平台支持软件模块的身份验证和授权，主要包括两个方面：
- 软件模块的识别和身份验证 ：软件平台需要能够在软件模块安装或加载执行时（或两者都有）对其进行识别和身份验证，通常通过软件签名来实现。流行的操作系统平台通常包含软件签名和验证的支持，但实际使用程度差异很大。
- 软件模块的权限授予和验证 ：需要有一种方法为执行的软件模块分配权限，并在软件模块请求访问资源（如特定于NAF的密钥）时检查权限。权限授予通常基于软件模块的身份验证。不同的操作系统在权限管理上有不同的粒度，例如Symbian OS支持按单个进程进行权限授予和验证，Security Enhanced Linux（SELinux）支持类似功能，Java安全架构则在对象级别提供更细粒度的支持。

3. GAA与身份管理系统的集成

个人身份管理对于使用多种服务的消费者来说是一个挑战，身份管理解决方案旨在解决这一问题。GAA可以与各种身份管理解决方案结合使用。

3.1 概述

身份管理系统通常允许最终用户向身份提供者（IdP）进行身份验证，然后将身份验证令牌或断言分发给其他需要验证用户身份的服务器（服务提供者SP或依赖方RP）。身份管理规范通常不强制规定单一的身份验证方式，而是提供多种身份验证机制，并允许添加新的机制。因此，GAA可以用于向以下系统的IdP进行用户身份验证：
- Liberty Alliance Project Identity Federation Framework（ID - FF）Version 1.2或Organization for the Advancement of Structured Information Standards（OASIS）Security Assertion Markup Language（SAML）Version 2.0，客户端应用程序通常是浏览器，无需了解身份管理系统。
- Liberty Alliance Project Identity Web Service Framework（ID - WSF）Version 2.0，客户端需要了解身份管理系统。
- OASIS WS - SX（Secure Exchange），客户端也需要了解身份管理系统，例如Microsoft’s CardSpace。
- OpenID 2.0，客户端是浏览器，无需了解身份管理系统。

客户端应用程序需要能够确定使用GAA进行身份验证，从GBA模块获取GAA凭证，并在与IdP的特定应用协议中使用这些凭证。例如，浏览器可以通过在HTTP Digest身份验证实现中添加必要的钩子，使其在IdP请求时自动使用GAA凭证作为用户名和密码。

3.2 GAA与Liberty ID - FF的互操作性

以GAA与Liberty ID - FF的互操作性为例，其工作流程如下：
1. 用户请求服务 ：服务用户输入标识服务的URL，该服务由Liberty SP托管，发送正常的HTTP GET请求。SP检查请求和服务策略，若发现用户未认证，则将浏览器重定向到Liberty IdP；若已认证，则跳过后续部分步骤。
2. SP重定向浏览器到IdP ：SP使用HTTP响应代码‘302 Found’将浏览器重定向到IdP，响应头中包含IdP的URL和认证完成后返回SP服务的嵌入式URL。
3. 浏览器向IdP发送请求 ：浏览器按照指示向IdP发送HTTP GET请求。若IdP发现用户在本次会话中未认证且已配置使用GAA进行身份验证，则发送HTTP响应代码‘401 Unauthorized’的身份验证挑战，并在WWW - Authenticate头中包含特殊参数。
4. 浏览器获取GAA凭证 ：浏览器检查身份验证挑战，发现特殊参数后，尝试从本地GBA模块获取特定于IdP的GAA凭证（即作为NAF的IdP的特定于NAF的密钥）。
5. 浏览器请求IdP特定密钥 ：浏览器向本地GBA模块请求计算身份验证响应所需的特定于IdP的密钥，并提供IdP的NAF_ID作为输入参数。
6. GAA引导过程 ：如果没有有效的GAA引导会话，GBA模块将与USIM、BSF和HSS一起执行GAA引导过程。
7. GBA模块生成IdP特定密钥 ：GBA模块使用GAA主会话密钥、NAF_ID和其他参数生成特定于IdP的密钥，并将其与收到的B - TID和密钥生命周期一起提供给浏览器。
8. 浏览器计算身份验证响应并发送请求 ：浏览器使用B - TID作为用户名，特定于IdP的密钥（Ks_NAF）作为密码，计算HTTP Digest挑战的身份验证响应，并将包含该响应的HTTP GET请求发送给IdP。
9. IdP请求GAA凭证 ：IdP收到身份验证响应后，提取B - TID，并使用B - TID和其NAF_ID向BSF请求特定于IdP的GAA凭证（Ks_NAF），还可能包含额外的GAA服务标识符（GSIDs）。
10. BSF响应IdP ：BSF根据B - TID定位GAA引导会话，使用会话的GAA主会话密钥和其他参数生成GAA NAF密钥，并根据本地策略决定是否包含IP多媒体私有身份（IMPI）和请求的USSs。
11. IdP验证响应并重定向浏览器 ：IdP使用GAA凭证和B - TID验证浏览器发送的身份验证响应。若验证成功，IdP构造并数字签名AuthnResponse断言，创建Artifact元素并将其映射到该断言，然后使用HTTP响应代码‘302 Found’将浏览器重定向回SP，并包含Artifact元素。
12. 浏览器向SP发送请求 ：浏览器按照指示向SP发送HTTP GET请求。
13. SP提取Artifact元素 ：SP收到请求后，提取Artifact元素。
14. SP验证用户身份 ：SP使用Artifact元素从IdP获取AuthnResponse断言并进行验证。若验证成功，则成功验证最终用户身份，并将经过身份验证和授权的初始请求转发到SP中的实际服务。
15. 服务返回响应 ：服务根据执行的服务逻辑返回响应给浏览器。后续请求通过嵌入的会话信息进行识别，SP会检查会话信息的有效性，若用户注销或会话超时，会话将失效。

下面是这个流程的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(服务用户输入URL):::process --> B(SP检查请求和策略):::process
    B -->|用户未认证| C(SP重定向到IdP):::process
    C --> D(浏览器向IdP发送请求):::process
    D -->|IdP配置GAA| E(IdP发送身份验证挑战):::process
    E --> F(浏览器获取GAA凭证):::process
    F --> G(浏览器请求IdP特定密钥):::process
    G --> H(GAA引导过程):::process
    H --> I(GBA模块生成IdP特定密钥):::process
    I --> J(浏览器计算响应并发送请求):::process
    J --> K(IdP请求GAA凭证):::process
    K --> L(BSF响应IdP):::process
    L --> M(IdP验证响应并重定向):::process
    M --> N(浏览器向SP发送请求):::process
    N --> O(SP提取Artifact元素):::process
    O --> P(SP验证用户身份):::process
    P --> Q(服务返回响应):::process
    B -->|用户已认证| R(跳过部分步骤):::process
    D -->|用户已认证| R

以上就是GAA部署相关内容的上半部分，主要介绍了GAA的访问控制和与身份管理系统的集成，下半部分将继续探讨GAA与移动网络的集成等内容。

GAA部署指南：从访问控制到网络集成

4. GAA与移动网络的集成

对于移动网络运营商（MNO）而言，在网络中部署GAA会面临一些挑战。其中，将HLR集成到GAA是一个关键问题。

4.1 HLR集成到GAA的情况分析

移动用户数据库是运营商的重要资产，其可用性对于提供各类移动服务（如语音和短信）至关重要。因此，运营商在将用户数据库从HLR更新到HSS时通常比较谨慎。

一个完整的GAA（包括GBA_U）需要具有特定GAA功能且支持基于Diameter的Zh接口的HSS。Zh接口能够携带GUSS（所有USS的集合），GUSS中的字段可指示用户是否拥有支持GBA_U的UICC。这一信息能使BSF更改接收到的认证向量并导出正确的密钥。

但如果仅为GBA_ME生成特定于NAF的密钥，BSF只需从用户数据库获取认证向量。这使得在不使用Zh接口的情况下，也可以使用HLR或HSS，因为可以通过MAP协议请求和接收向量。基于MAP的与HLR/HSS的接口被称为Zh’。由于MAP接口不支持GUSS，且规范中不打算在HLR中存储USS，因此使用Zh’接口的BSF将无法使用依赖于GUSS的GAA功能，如GBA_U支持。

3GPP在各个版本中对网络节点和协议进行标准化。GAA在版本6和7中被规范，2007年也开始了版本8的相关工作。通常，规范和报告仅基于同一版本中的功能和节点构建。在规范创建过程中，会考虑不同版本之间的互操作性，并避免或至少捕捉系统故障以防止系统崩溃。然而，实际的部署和推广计划往往有所不同，这有时也会反映在规范工作中。例如，网络运营商可能希望在不将用户数据库更新为HSS或不向用户发放新智能卡的情况下推出广播移动电视服务。更新用户数据库还可能引发相关节点的“后续”更新，这给新服务带来了风险，因为新服务的推出和成功时间难以准确预测。因此，3GPP在相关文档中规范了版本5或更早版本的HLR以及不支持Diameter的HSS与版本7或版本8的BSF的互操作性。

具体来说，BSF与用户数据库的交互有两种方式：
- 使用基于Diameter的Zh接口 ：这是与HSS交互的强制接口。
- 使用基于MAP的Zh’接口 ：这是与HLR或不支持Zh的HSS交互的可选接口。在Zh’接口中，用于获取认证向量的消息已用于运营商间漫游，或者在某些情况下用于节点内部接口（如果HSS由HLR和HSS附加组件组成）。这些内部接口通常未被标准化。BSF可以通过发送MAP_SEND_AUTHENTICATION_INFO请求从HLR获取认证向量，HLR已经支持该MAP消息用于VLR节点的漫游用户和SGSN节点，不支持Zh或Diameter的HSS也支持该消息。

以下是不同版本的用户数据库向支持GAA的迁移情况表格：
| 原数据库状态\目标数据库状态 | R4 HLR with GAA | R5 HLR with GAA | R5 HSS with GAA | R6 HSS with GAA | R7 HSS with GAA |
| — | — | — | — | — | — |
| R4 HLR without GAA | Add Zh′ | Upgrade to R5 and add Zh′ | Upgrade to R5 HSS and add Zh′ | Upgrade to R6 HSS and add Zh′ or Zh | Upgrade to R7 HSS and add Zh′ or Zh |
| R5 HLR without GAA | X | Add Zh′ | Upgrade to R5 HSS and add Zh′ | Upgrade to R6 HSS and add Zh′ or Zh | Upgrade to R7 HSS and add Zh′ or Zh |
| R5 HSS without GAA | X | X | Add Zh′ | Upgrade to R6 HSS and add Zh′ or Zh | Upgrade to R7 HSS and add Zh′ or Zh |
| R6 HSS without GAA | X | X | X | Add Zh′ or Zh | Upgrade to R7 HSS and add Zh′ or Zh |
| R6 HSS with GAA | X | X | X | X | Upgrade to R7 HSS |
| R7 HSS without GAA | X | X | X | X | Add Zh′ or Zh |

下面是BSF与用户数据库交互的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(BSF需要认证向量):::process -->|可选| B(Zh′接口向HLR/HSS请求):::process
    A -->|强制| C(Zh接口向HSS请求):::process
    B --> D(HLR/HSS返回向量):::process
    C --> D
    D --> E(BSF生成特定于NAF的密钥):::process

总结

综上所述，GAA的部署涉及多个方面，包括访问控制、与身份管理系统的集成以及与移动网络的集成。在访问控制方面，通过基本访问控制和扩展访问控制设计选项，能够保障系统的安全性。与身份管理系统的集成，使得GAA可以与多种身份管理解决方案结合使用，为用户提供更便捷的身份验证服务。而在与移动网络的集成中，HLR与GAA的集成情况需要根据实际需求和网络现状进行选择。网络运营商在部署GAA时，需要综合考虑这些因素，以实现安全、高效的网络服务。