跳到主要内容

1. 简介 (Introduction)

Internet of Things 在许多维度上带来了管理挑战. 其中之一是能够引导并管理大量设备. 在设备与网络部署之间建立信任有多种模型. 实际上, 预期不同制造商会使用不同方法.

System for Cross-domain Identity Management (SCIM) [RFC7643] [RFC7644] 定义了用于供应用户的协议和模式. 但是, 它也可以很容易扩展, 用于将设备凭据和其他属性供应到网络中. 该协议和核心模式在设计时就允许这种扩展. 它支持批量操作. 这很有用, 因为设备通常会批量采购.

本规范的主要目的之一是基于设备的底层能力, 为本地部署中的设备 onboarding 以及进出设备的通信访问供应网络.

某些设备的底层安全机制范围很宽, 从几乎不存在安全性的 Bluetooth Low Energy (BLE) "Just Works" pairing method, 到健壮的 FIDO Device Onboard (FDO) 机制都有. 来自 SCIM server 的信息会基于所选 schema extensions 分发给控制功能, 以便在网络内启用这些通信. 因此, SCIM database 本质上等同于网络的 Authentication, Authorization, and Accounting (AAA) database, 并且应以同等谨慎方式管理.

1.1. 为什么设备使用 SCIM?​

有许多现有模型可以作为将设备供应到网络中的方案基础, 其中包括 IETF 标准化的两种: NETCONF [RFC6241] 或 RESTCONF [RFC8040] 结合 YANG [RFC7950]. 选择 SCIM 的原因如下:

  • NETCONF 和 RESTCONF 关注的是配置, 而不是 provisioning.

  • SCIM 的设计考虑了跨域 provisioning. 使用 HTTP 作为底层承载, 既允许本地 provisioning 应用使用基于用户的认证, 也允许使用 OAUTH 或基于证书的认证. 这些操作的跨域性质不会暴露本地策略. 本地策略本身必须, 且通常确实会, 通过其他 API 配置, 其中很多 API 并未标准化.

  • SCIM 也是企业环境中熟悉的工具, 被广泛用于配置联合用户账号.

  • 最后, 一旦选择 SCIM 这样的载体, 就必须受其数据模型约束. 如 [RFC7643] 所述, SCIM 数据模型更针对 provisioning.

将这些因素与终端设备并非意图被直接配置这一事实结合起来, SCIM 就成为最佳标准选项.

1.2. 协议参与方​

在普通 SCIM 模型中, 大型联合部署被假定为 SCIM clients. 当员工和承包商进入或离开这些部署时, 它们会供应和移除这些人员. 销售, 支付或会议服务等联合服务则是 servers.

在设备模型中, 这些角色被反转, 并且可能更加多样. SCIM server 位于某个部署内部, 用于接收预计将连接到其网络的设备信息. 该 server 会应用适当的本地策略, 决定设备是否以及如何连接.

client 可以是多种实体之一:

  • 被授权作为销售交易一部分向网络添加设备的 vendor. 这类似于 Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] 有时设想的销售集成.

  • 管理员或员工用于添加, 移除或获取设备信息的 client application. 示例可能是扫描 Wi-Fi Easy Connect QR codes 的平板或手机应用.

                               +-----------------------------------+
                               |                                   |
       +-----------+   Request |  +---------+                      |
       | Onboarding|------------->|  SCIM   |                      |
       |    App    |<-------------| Server  |                      |
       +-----------+  Ctrl Endpt  +---------+                      |
                               |       |                           |
                               |       |(Device Info)              |
                               |       v                           |
       +-----------+           |  +------------+         +-------+ |
       |  Control  |...........|..|    ALG     |.........|Device | |
       |    App    |           |  +------------+         +-------+ |
       +-----------+           |                                   |
                               |         Local Network             |
                               +-----------------------------------+

               Figure 1: Basic Architecture - Non-IP Example

在图 1 中, onboarding application (app) 提供设备详细信息. 这些信息会根据设备类型而变化, 并由所选 schema extensions 指示. 作为响应的一部分, SCIM server 可能提供额外信息, 尤其是在 non-IP devices 的情况下, 此时可能需要使用 application-layer gateway 与设备通信 (c.f., [NIPC]). control endpoint 是可能返回的多个对象之一. 随后该 control endpoint 将与 Application Layer Gateway (ALG) 通信以到达设备.

                               +------------------------------------+
                               |                                    |
       +-----------+   Request |  +---------+   +----+    +------+  |
       | Onboarding|------------->|  SCIM   |-->| AAA|<-->|Switch|  |
       |    App    |<-------------| Server  |   +----+    +------+  |
       +-----------+  Ctrl Endpt  +---------+                |      |
                               |                             |      |
       +-----------+           |  +------------+         +-------+  |
       |  Control  |...........|..| Router/fw  |.........|Device |  |
       |    App    |           |  +------------+         +-------+  |
       +-----------+           |                                    |
                               |          Local Network             |
                               +------------------------------------+

                       Figure 2: Interaction with AAA

图 2 展示了如何供应基于 IP 的 endpoints. 在这种情况下, onboarding application 通过 SCIM 供应设备. 必要信息会传递给 Authentication, Authorization, and Accounting (AAA) subsystem, 以允许设备连接. 一旦设备上线, 由于它基于 IP, 就不需要 ALG, 而会使用普通 IP 基础设施与其 control application 通信.

1.3. 模式描述​

[RFC7643] 没有规定用于描述 schema 的语言, 而是使用带示例的叙述性描述. 本文档遵循这种方法. 此外, 为便于实现, 我们在附录中提供非规范性的 JSON Schemas [JSONSchema] 和 OpenAPI [OpenAPI] 版本. 这些内容在 SCIM 最初开发时尚不存在. 作者注意到, 规范性模式表示与这些版本之间的唯一区别是 JSON Schemas 和 OpenAPI 版本没有表达大小写敏感性的方式, 因此不区分大小写的属性必须手动验证.

若干附加 schemas 指定具体 onboarding mechanisms, 例如 Bluetooth Low Energy (BLE) [BLE54], Wi-Fi Easy Connect [DPP2] 和 FIDO Device Onboard [FDO11].

当本备忘录中展示 JSON 时, 会按照 [RFC8792] 进行折行.

1.4. 模式表示​

设备核心 schema 中定义的属性 (见 [RFC7643] 第 2.2 节) 和扩展由 characteristics 以及 SCIM datatypes (定义见 [RFC7643] 第 2.3 节) 组成. 本规范没有为 SCIM attributes 定义新的 characteristics 和 datatypes.

1.5. 术语​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 按 BCP 14 [RFC2119] [RFC8174] 中的描述解释, 但仅当它们以此处所示的全大写形式出现时才如此解释.

还预期读者熟悉 [RFC7643] 中使用的叙述性 schema language.

最后于 更新