《5G核心网原理与实践》实践篇 · BSF 网元功能
作者：爱卫生
在前面的文章中，我们详细讨论了BSF如何创建和存储会话绑定信息。但一个关键的安全问题随之而来：谁有权查询这些绑定信息？
在5GC服务化架构中，BSF作为一个服务生产者（Service Producer），对外提供Nbsf_Management服务。任何NF（如AF、NEF、PCF等）理论上都可以通过NRF发现BSF并发起服务请求。然而，在运营商实际部署中，并非所有网元都有权限访问BSF的绑定信息——这涉及到网络安全的最小权限原则。
本篇聚焦BSF的服务授权（Service Authorization）机制，验证BSF如何对服务消费者（Service Consumer）进行鉴权，以及BSF如何通过NRF的allowedNfTypes机制实现白名单式的访问控制。
在5GC中，BSF的服务授权主要通过以下两种机制实现：
机制一：NRF级别的NF类型过滤（allowedNfTypes）
BSF在向NRF注册时，可以在NFProfile中携带allowedNfTypes参数，指定哪些NF类型（如AF、NEF）有权限发现并访问BSF的服务。NRF在处理服务发现请求时，会检查请求方的NF类型是否在允许列表中，不在列表中的NF将无法发现BSF，从而从源头阻断了未授权的访问。
机制二：BSF本地的服务鉴权
BSF自身也可以维护一个访问控制列表（ACL），对发起请求的消费者进行进一步的鉴权检查。这种方式更加灵活，可以基于NF实例ID、NF类型、甚至具体的API路径进行细粒度的访问控制。
本测试用例同时验证了这两种机制。
sequenceDiagram
participant Consumer1 as Consumer1-AF
participant Consumer3 as Consumer3-NEF
participant Consumer2 as Consumer2-非授权NF
participant NRF as NRF
participant BSF as SMF/BSF
Note over BSF, NRF: 步骤1: BSF配置服务鉴权
BSF->>NRF: NFRegister Update (携带allowedNfTypes: AF, NEF)
NRF-->>BSF: 200 OK
Note over Consumer1, NRF: 步骤2: Consumer1-AF发起服务发现
Consumer1->>NRF: GET /nnrf-nfm/v1/nf-instances?nf-type=BSF
Note right of Consumer1: Consumer1的NF类型=AF<br/>在allowedNfTypes中
NRF-->>Consumer1: 200 OK (返回BSF的NFProfile)
Consumer1->>BSF: GET /nbsf-management/v1/pcfBindings
BSF-->>Consumer1: 200 OK (返回绑定信息)
Note over Consumer3, NRF: 步骤3: Consumer3-NEF发起服务发现
Consumer3->>NRF: GET /nnrf-nfm/v1/nf-instances?nf-type=BSF
Note right of Consumer3: Consumer3的NF类型=NEF<br/>在allowedNfTypes中
NRF-->>Consumer3: 200 OK (返回BSF的NFProfile)
Consumer3->>BSF: GET /nbsf-management/v1/pcfBindings
BSF-->>Consumer3: 200 OK (返回绑定信息)
Note over Consumer2, NRF: 步骤4: Consumer2-非授权NF发起服务发现
Consumer2->>NRF: GET /nnrf-nfm/v1/nf-instances?nf-type=BSF
Note right of Consumer2: Consumer2的NF类型不在<br/>allowedNfTypes中
NRF-->>Consumer2: 403 Forbidden (拒绝服务发现)
flowchart TD
A["Consumer发起BSF服务发现请求"] --> B["NRF检查Consumer的NF类型"]
B --> C["NF类型在allowedNfTypes中"]
B --> D["NF类型不在allowedNfTypes中"]
C --> E["NRF返回BSF的NFProfile"]
E --> F["Consumer访问BSF服务"]
F --> G["BSF本地鉴权"]
G --> H["鉴权通过: 返回绑定信息"]
G --> I["鉴权失败: 拒绝请求"]
D --> J["NRF返回403 Forbidden"]
style H fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style I fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style J fill:#ffcdd2,stroke:#c62828,stroke-width:2px
验证BSF支持对Service Consumer进行服务鉴权及提供白名单功能。具体验证BSF能够通过NRF的allowedNfTypes机制和本地鉴权机制，控制哪些NF可以访问BSF的会话绑定信息查询服务。
网络中SMF/BSF网元系统及操作维护台运行正常。
BSF已完成在NRF中的服务注册。
已准备多个不同NF类型的消费者（Consumer1=AF，Consumer2=其他NF类型，Consumer3=NEF）。
5G用户已完成PDU会话建立，BSF中存在会话绑定信息。
服务化接口的信令监控与分析工具准备就绪。
在BSF上对使用会话绑定信息查询服务的Consumer进行鉴权配置。配置内容包括NF type，允许Consumer1进行服务访问，禁止Consumer2进行服务访问。
5G用户发起会话建立请求，在BSF上生成对应的会话绑定信息。
Consumer1（被允许的NF类型）发起会话绑定信息查询服务请求。
Consumer2（被禁止的NF类型）发起会话绑定信息查询服务请求。
BSF进行注册更新，在NFProfile中携带allowedNfTypes，填写AF和NEF。
Consumer1（AF）和Consumer3（NEF）向NRF发起BSF服务发现、BSF订阅请求。
Consumer2（非AF和NEF）向NRF发起BSF服务发现、BSF订阅请求。
BSF能配置服务鉴权信息，指定允许和禁止访问的NF类型。
BSF允许Consumer1的服务访问，返回正确的绑定信息。
BSF拒绝Consumer2的服务访问，返回错误响应。
BSF在注册更新请求中携带了allowedNfTypes，填写AF和NEF。
NRF成功响应Consumer1和Consumer3的BSF服务发现、BSF订阅请求。
NRF发送403拒绝Consumer2的BSF服务发现、BSF订阅请求。
本测试涉及两层鉴权机制的信令交互：BSF本地鉴权和NRF级别的NF类型过滤。下面逐步解析每个环节。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP及实例ID等敏感信息已做严格脱敏处理）
在测试鉴权之前，首先需要确保BSF中存在会话绑定信息。通过5G用户建立PDU会话，触发BSF创建绑定记录。
UE用户上下文：
[local]SMF02#epg smf user-info identifier-type imsi value 460XX00000XXYY
mobile-user-information:
subscriber-information:
imsi: 460XX00000XXYY
msisdn: 86138000XXYY
imei: XXXXXXXXXXXXXXXX
active-pdu-sessions:
active-pdu-session:
pdu-session-id: 5
dnn-in-use: apn2
an-type: 3GPP
ssc-mode: SSC_MODE_1
ue-address-1:
ipv4: 10.XX.XX.XX
ip-address-allocation-method: Shared IP Pool
single-nssai:
slice-service-type: 2
slice-differentiator: 000001
nr-location:
tai:
plmn-id: mncXX.mcc460
tac: 3
ncgi:
plmn-id: mncXX.mcc460
nr-cell-id: 262144
amf-information:
amf-id: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
address: 10.XX.XX.XX:8080
n3-interface:
ran-fteid:
teid: 1342197281
address: 10.XX.XX.XX
upf-fteid:
teid: 597688321
address: 10.XX.XX.XX
n4-interface:
local-fseid:
seid: 148061344
address: 10.XX.XX.XX
remote-fseid:
seid: 5134103575202365441
address: 10.XX.XX.XX
qos-flows:
qos-flow:
qos-flow-id: 5
fiveQi: 5
allocation-retention-priority:
priority-level: 1
pre-emption-capability: Disabled
pre-emption-vulnerability: Disabled
session-ambr:
uplink-kbps: 50000
downlink-kbps: 150000
BSF绑定信息查询验证：
[local]SMF02#epg smf sbi bsf-services show-pcf-binding-info address 10.XX.XX.XX
pcf-binding-information:
snssai-sst: 2
snssai-sd: 000001
ueIp: 10.XX.XX.XX
dnn: apn2
supi: 460XX00000XXYY
gpsi: 86138000XXYY
pcfId: 4444c290-3621-4d72-b718-e0194603ab11
pcfDiameterHost: rxDiam-Host.com
pcfDiameterRealm: rxDiam-Realm.com
pcfIpEndPoints: 10.XX.XX.XX:9091
绑定信息已成功创建，为后续鉴权测试提供了数据基础。
BSF在配置服务鉴权信息后，需要向NRF进行注册更新，在NFProfile中携带allowedNfTypes参数。这一步是NRF级别访问控制的关键——NRF将根据此参数决定哪些NF类型可以发现BSF。
sequenceDiagram
participant BSF as SMF/BSF
participant NRF as NRF
Note over BSF, NRF: BSF注册更新携带allowedNfTypes
BSF->>NRF: PATCH /nnrf-nfm/v1/nf-instances/{bsfInstanceId}
Note right of BSF: 请求体携带:<br/>allowedNfTypes: [AF, NEF]<br/>表示只允许AF和NEF发现BSF
NRF-->>BSF: 200 OK
Note left of NRF: NRF更新BSF的NFProfile<br/>存储allowedNfTypes信息
注册更新请求关键参数：
PATCH /nnrf-nfm/v1/nf-instances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
JavaScript Object Notation: application/json
Object
Member Key: nfInstanceId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Member Key: nfType
String value: "BSF"
Member Key: allowedNfTypes
Array
String value: "AF"
# 允许AF类型的NF发现BSF
String value: "NEF"
# 允许NEF类型的NF发现BSF
Member Key: nfServices
Array
Object
Member Key: serviceName
String value: "nnbsf_management"
Member Key: allowedNfTypes
Array
String value: "AF"
String value: "NEF"
| 参数 | 含义 | 说明 |
|---|---|---|
allowedNfTypes (顶层) |
NF级别允许类型 | 只有AF和NEF可以发现此BSF |
|---|---|---|
allowedNfTypes (服务级) |
服务级别允许类型 | 只有AF和NEF可以使用nnbsf_management服务 |
协议参考：根据3GPP TS 29.510第6.1.6.2.3节，NFProfile中的
allowedNfTypes参数定义了哪些NF类型允许通过NRF发现该NF。NRF在处理服务发现请求时，会检查请求方的NF类型是否在目标NF的allowedNfTypes列表中。如果不在列表中，NRF将返回403 Forbidden。
Consumer1的NF类型为AF，在BSF的allowedNfTypes列表中，因此可以成功发现BSF并访问其服务。
服务发现请求：
# Consumer1 (AF) 向NRF发起BSF服务发现
GET /nnrf-nfm/v1/nf-instances?nf-type=BSF&target-nf-type=AF
Host: 10.XX.XX.XX:8080
Authorization: Bearer XXXX
# NRF响应
HTTP/1.1 200 OK
JavaScript Object Notation: application/json
Object
Member Key: nfInstances
Array
Object
Member Key: nfInstanceId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Member Key: nfType
String value: "BSF"
Member Key: ipv4Addresses
Array
String value: "10.XX.XX.XX"
Member Key: nfServices
Array
Object
Member Key: serviceName
String value: "nnbsf_management"
Member Key: apiPrefix
String value: "http://10.XX.XX.XX:8080"
BSF服务访问请求：
# Consumer1 (AF) 向BSF发起会话绑定信息查询
GET /nbsf-management/v1/pcfBindings?ipv4Addr=10.XX.XX.XX&dnn=apn2
Host: 10.XX.XX.XX:8080
Authorization: Bearer XXXX
# BSF响应
HTTP/1.1 200 OK
JavaScript Object Notation: application/json
Object
Member Key: bindingId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Member Key: supi
String value: "imsi-460XX00000XXYY"
Member Key: ipv4Addr
String value: "10.XX.XX.XX"
Member Key: dnn
String value: "apn2"
Member Key: pcfId
String value: "4444c290-3621-4d72-b718-e0194603ab11"
Member Key: pcfIpEndPoints
Array
Object
Member Key: ipv4Address
String value: "10.XX.XX.XX"
Member Key: port
Number value: 9091
Consumer1（AF）成功获取了会话绑定信息。
Consumer2的NF类型不在BSF的allowedNfTypes列表中，因此在NRF服务发现阶段就被拒绝，根本无法获取BSF的地址信息。
# Consumer2 (非AF/NEF) 向NRF发起BSF服务发现
GET /nnrf-nfm/v1/nf-instances?nf-type=BSF&target-nf-type=OtherNF
Host: 10.XX.XX.XX:8080
Authorization: Bearer XXXX
# NRF响应
HTTP/1.1 403 Forbidden
JavaScript Object Notation: application/json
Object
Member Key: cause
String value: "NOT_ALLOWED"
Member Key: detail
String value: "Target NF type not in allowedNfTypes"
鉴权结果对比：
| Consumer | NF类型 | allowedNfTypes | NRF响应 | BSF访问 |
|---|---|---|---|---|
| Consumer1 | AF | 包含AF | 200 OK | 允许访问 |
| Consumer2 | OtherNF | 不包含 | 403 Forbidden | 无法发现BSF |
| Consumer3 | NEF | 包含NEF | 200 OK | 允许访问 |
BSF的服务授权是5GC整体安全框架的一个组成部分。根据3GPP TS 33.501的安全架构定义，5GC服务化接口的安全保障分为以下几个层次：
flowchart TD
A["5GC SBI安全体系"] --> B["第一层: 传输安全-TLS"]
A --> C["第二层: 认证-OAuth2.0"]
A --> D["第三层: 授权-allowedNfTypes"]
A --> E["第四层: 审计-日志记录"]
B --> B1["所有SBI通信使用TLS加密"]
B --> B2["双向认证: NF和NRF互相验证证书"]
C --> C1["NF向OAuth服务器获取Access Token"]
C --> C2["请求携带Bearer Token"]
C --> C3["BSF验证Token有效性"]
D --> D1["NRF级别: allowedNfTypes过滤"]
D --> D2["BSF级别: 本地ACL鉴权"]
style A fill:#e3f2fd,stroke:#1565c0,stroke-width:3px
style C fill:#e8f5e9,stroke:#2e7d32
style D fill:#fff3e0,stroke:#e65100
OAuth2.0授权流程详解：
在本测试中，虽然主要验证的是allowedNfTypes机制，但完整的BSF服务授权还涉及OAuth2.0令牌认证。完整流程如下：
Consumer获取Access Token：AF/NEF在访问BSF之前，首先向授权服务器（如NRF内嵌的Authorization Function）发送OAuth2.0令牌请求，获取Access Token；
Consumer携带Token访问BSF：AF/NEF在向BSF发送请求时，在HTTP Authorization头中携带Bearer Token；
BSF验证Token：BSF收到请求后，验证Token的有效性（签名、过期时间、权限范围等）；
BSF本地鉴权：Token验证通过后，BSF还会检查本地的ACL，确认该Consumer是否有权限访问所请求的资源。
| 安全层次 | 机制 | 验证方 | 本测试覆盖 |
|---|---|---|---|
| 传输加密 | TLS 1.2/1.3 | 双向 | 依赖基础设施 |
| 身份认证 | OAuth2.0 Token | BSF | 部分覆盖 |
| 访问授权 | allowedNfTypes | NRF | 完全覆盖 |
| 本地鉴权 | BSF ACL | BSF | 完全覆盖 |
协议参考：根据3GPP TS 29.551第6.1节和TS 33.501第13.3节，BSF的服务安全应遵循5GC SBI安全通用框架。BSF应支持基于OAuth2.0的访问令牌验证，以及基于NF类型的访问控制。
allowedNfTypes机制在TS 29.510中定义，是NRF服务发现流程中的标准授权检查机制。
| 验证项 | 结果 | 说明 |
|---|---|---|
| BSF鉴权配置 | OK | 支持基于NF类型的服务鉴权配置 |
| allowedNfTypes携带 | OK | BSF注册更新时正确携带AF和NEF |
| AF发现BSF | OK | Consumer1-AF成功发现BSF并获取绑定信息 |
| NEF发现BSF | OK | Consumer3-NEF成功发现BSF并获取绑定信息 |
| 非授权NF被拒绝 | OK | Consumer2被NRF返回403 Forbidden |
| BSF本地鉴权 | OK | BSF根据配置允许/拒绝服务访问 |
本测试用例全面验证了BSF的服务授权机制。测试结果表明，BSF通过两层安全机制保障会话绑定信息的安全访问：NRF级别的allowedNfTypes过滤从服务发现源头阻断了未授权NF的访问；BSF本地的ACL鉴权提供了细粒度的访问控制。两种机制协同工作，确保只有经过授权的AF和NEF才能查询会话绑定信息，有效防止了未授权的数据泄露。所有信令流程与3GPP TS 29.551、TS 29.510和TS 33.501规范一致。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101