工业互联网是互联网与工业生产相结合而形成的交集，主要由智能机器、高级分析、工作人员三个元素构成。现实世界中的机器、设备、团队和网络通过传感器、控制器和软件应用程序连接起来，并使用基于物理的分析法、预测算法、自动化和材料科学，电气工程及其他关键学科知识来理解机器与大型系统的运作方式^[1-2]。工业互联网的价值不仅仅体现于企业内部的基于大数据形成的智能制造能力，更为产业界的资源分享与制造能力的协作提供了基础模式。智能制造需要突破单一企业的边界，制造资源与生产力的社会化分享促进了企业间合作联盟的形成，通过产业链实现资源的弹性化组织和应用。在此产业链的构成过程中，涉及到设计者、制造者、销售者、集成与咨询者、服务者和运维者。上述所有对象通过信息-物理空间系统(cyber-physical system,CPS)构成完整协同平台，在CPS中，企业之间并非具有从属特性，对象之间的联合也不具有恒定的合作关系^[3]。他们之间通过虚拟组织(virtual organization，VO)的临时关系来定义。

对各制造服务提供商而言，VO的跨域服务联合带来的安全性需求可能会高于业务逻辑本身。长久以来，国际上许多机构都在积极推动跨组织认证和授权的标准化工作，并制定了安全声明标记语言(security assertion markup language，SAML)^[4]和WS-Security系列标准。基于这些标准，文献^[5]提出跨域服务联合安全框架，阐述跨域服务联合中的安全功能，包括信任拓扑管理、跨域认证及授权、隐私保护等。文献^[6]提出智能制造的社会化协同机制，阐述了跨域松耦合联盟与紧耦合制造集团间的授权信息集成方法。

OAuth 2.0^[7-8]是OAuth协议的下一版本，关注服务请求方的简易性，为Web应用、移动设备等提供专门的认证流程。它使得服务请求方通过经由用户授权而获得的访问令牌(access token)来使用用户在服务提供方的资源和服务，代表用户执行相关操作，从而避免了直接将用户的凭据(如口令)交给服务请求方。建立在OAuth 2.0上的OpenID Connect(OIDC)^[9]，是OpenID的下一版本，提供了开放的身份认证，其跨域工作的方式，很适合VO中不同服务提供商之间的用户共享。

1 VO服务联合安全需求

VO是一个以动态市场机会为基础的各种核心能力的统一体，组织内各成员异地、异构、无产权联系，相互之间的合作关系是动态的，完全突破了以内部组织制度为基础的传统组织结构。合作是VO存在的基础，但由于VO各成员保持着自己原有的风格松散耦合，彼此间由于信任产生的安全问题尤为突出。

为清晰阐述VO服务联合安全问题，本文给出了一组服务联合典型示例，如图 1所示。

A、B与C为三个彼此独立的域。A1、A2、A3、A4是A域的服务，B域和C域的服务类似，其中B2是一项与用户无关的公共服务。各个域有自己独立的授权服务器AS(含认证功能)，并可选地提供OpenID服务。Third Party OP/IDP (OpenID Provider)为第三方OpenID服务提供方。示例中包含三种典型的服务联合场景：A域的服务A1调用了本域了服务A2和外域的服务B1，A2和B1又分别跨域调用了服务C1和A3，是典型的跨域服务联合；C域中的服务C2依赖本域服务C3、C4和C5，属于同一安全域/信任域的服务联合，即同域服务联合；服务A4对服务B2的调用产生了(跨域)公共服务联合场景。

传统服务提供方仅对外提供安全的核心业务服务接口，仅需要在本域边界进行有效地防范即可确保本域的整体安全。加入VO的各成员组织出于跨域服务联合的需要，原本各自独立的安全边界遭到破坏，为VO服务联合引入了以跨域认证及授权为核心的安全问题。其中，跨域认证将可信的用户标识信息跨域共享，从而避免用户跨域使用服务资源时的重复认证；跨域授权则允许服务提供方和资源所有者对来自外域的资源使用请求进行授权控制。概括而言，服务联合场景中涉及四类安全问题：

1) 服务联合建立：为了使用户的认证与授权信息和服务资源能够在跨域环境下进行共享，跨域服务联合的建立就是要根据服务调用关系构建多域环境下的关联关系，从而形成由一系列服务分享与使用所形成的VO。

2) 单点登录(single sign-on，SSO)：在跨域服务联合中，用户只需要完成一次身份认证流程，即可访问所有服务，无需执行多次认证。

3) 联合退出(federated sign-out)：在跨域服务联合中，用户主动退出时，清理该服务联合中各服务相关的缓存数据，结束会话以保证会话安全。

4) 访问控制：受VO的松散耦合、分布式特点影响，跨域服务联合中需要对服务的跨组织访问进行严格明确地约束，以防止未授权访问。

2 VO服务联合安全方案

OAuth 2.0 和OIDC分别将授权与认证操作从业务逻辑中抽象出来，构成VO服务联合安全方案的基础。

OAuth 2.0能使VO服务联合场景中服务使用方代表自身或者通过引导用户(服务/资源所有者)与服务提供方进行一系列的授权交互后代表用户获取受限的服务，授权信息以Access Token形式返回给服务使用方作为访问受保护资源的凭据，每一个Access Token授权其持有者在特定的时间段内使用特定的服务。

OIDC作为OAuth 2.0协议授权过程的扩展，其身份认证结果为JWT(JSON web token)形式的ID Token。ID Token包含着认证相关的信息，而认证用户详细信息的获取则融入了授权流程，需要使用通过用户授权后得到的Access Token从资源服务器(resource server，RS)的UserInfo Endpoint处获取。

跨域服务联合、同域服务联合和公共服务联合由于安全域跨越和业务本身的不同，导致对授权的安全需求不同。本方案权衡安全性需求和授权流程的灵活性与授权效率，为VO的三种服务联合场景选用了不同的授权模式：

1) 在跨域服务联合中，服务使用方需要跨越安全域获得用户授权，安全需求最高，采用的是OAuth 2.0四种授权模式中功能完整、流程最为严密的授权码模式(authorization code)；

2) 在同域服务联合中，由于服务使用方与服务提供方处于同一个安全域中，彼此存在一定的信任基础，服务访问的授权可在用户身份验证后使用本域内的访问控制策略；

3) 在公共服务联合中，服务使用方以自身身份使用资源，并不涉及用户身份认证和请求用户授权的过程，服务提供方仅需对服务使用方身份进行认证即可，授权采用OAuth 2.0授权模式中的客户端模式(client credentials)。

基于OAuth 2.0和OIDC的用户认证授权过程受TLS的保护，能确保认证授权过程的安全。用于身份认证的ID Token使用了JWS(JSON web signature)来确保信息的完整性和可认证性，并且可采用JWE(JSON web encryption)加密以获得机密性保证。包含授权信息的Access Token由授权服务器(authorization server，AS)定义，通过数字签名机制确保无法篡改和伪造。

2.1 跨域服务联合

VO跨域服务联合场景中，首次进行跨域服务调用或后续服务调用时已有授权失效(授权过期或用户取消授权)的情况下，都需要用户进行身份认证后对服务请求方所请求资源/服务的访问进行授权。在用户通过身份认证并进行授权后，授权信息以Access Token形式返回给服务请求方。服务请求方在之后进行的服务调用请求中，携带该Access Token作为服务使用的的授权凭证。服务提供方则首先对请求信息中的Access Token进行有效性认证，在确认其完整性、有效性且授权涵盖本次服务请求后，再向服务请求方提供服务。

在图 1展示的跨域服务联合场景中，直接面向用户的服务A1需要使用外域服务以完成业务逻辑。由于业务流程分散在A、B、C三个域中，为统一用户管理，需要协商使用同一个OP/IDP(A、B、C三个域的IDP之一或第三方IDP)提供的身份认证服务，本文以选择第三方IDP为例进行描述。

以OIDC及OAuth 2.0的认证授权为基础动态建立的虚拟组织中各成员之间是松散耦合的。各VO成员独立提供授权服务(Authentication Service)、业务服务，并根据需求可选地提供OpenID服务。

跨域服务联合建立的前提是根据服务调用产生基于注册的关联关系。此场景中，由业务逻辑产生的跨域服务调用有＜A1,B1＞、＜A2,C1＞和＜B1,A3＞，此外A、B、C均使用了外域(第三方IDP)提供的OpenID服务，共计六个服务调用，亦即需要相应的六次注册以完成服务联合的建立。服务调用的注册过程与OAuth 2.0 协议一致，服务使用方向服务提供方提供该跨域服务调用的回调地址并获得自身标识及认证凭据。

用户首次使用服务A1时，认证与授权流程如图 2所示。

1) 用户首次访问A域的服务A1，且无法提供有效的身份信息，A1根据协商结果引导用户前往第三方IDP处进行身份认证并同时携带所需的用户身份信息请求；

2) 第三方IDP首先对用户身份进行合法性认证，认证成功后，引导用户对A1所请求的用户自身身份信息进行访问授权并根据用户的授权分发授权码(authorization code)给A1。A1通过此授权码从第三方IDP处换取用户身份标识令牌(ID Token)和访问令牌(Access Token)，此访问令牌可用于从IDP处获取用户授权访问的用户自身身份信息；

3) A1对服务A2的调用属于同域服务调用，仅需在服务调用请求中携带从步骤2)获取的ID Token即可，详细步骤参见2.2节；

4) A2初次跨域调用C1时，并没有用户对服务C1的使用授权，需要向C1发送授权请求，请求内容为A2需要以用户的身份在C1处使用的服务/资源；

5) 用户在C域并未进行登录认证，故C1需要引导用户前往第三方IDP出进行认证操作并同时携带所需的用户身份信息请求；

6) 由于步骤1) 中用户已经在IDP处认证过(短时间内，会话未失效)，通过OIDC的会话管理功能^[10]，用户在此步骤将直接通过身份认证进入OIDC的用户身份信息授权流程，之后的流程与步骤2)类似，C1得到ID Token和授权用于访问用户身份信息的Access Token；

7) C1引导用户对A2请求的资源进行访问授权并根据用户授权分发授权码给A2，A2获得授权码并进一步从C1得到Access Token。A2在之后代表该用户对C1的服务请求中携带该Access Token作为访问凭证；

8) ~11) 与步骤4) ~7) 类似；

12) B1初次调用服务A3，需要向A3发送授权请求，请求内容为B1需要以用户的身份在A3处使用的资源；

13) 此步骤中，用户已经在A域通过身份认证，会话有效，故直接进入用户授权操作流程，其余流程与步骤7)类似。

以上流程涉及A、B、C三个域对用户身份的认证和三次跨域服务调用，显式的授权操作需要进行三次(不含身份认证过程中用户对访问自身身份信息的授权)，每次跨域服务调用对应一次授权过程；共三个域的身份认证需求仅需要用户在第三方IDP处进行一次登录认证，实现了单点登录。

单点登录功能基于OIDC协议的会话管理扩展部分，通过特定方法让A、B、C三个域共享了第三方OP/IDP的认证会话，从而可以使VO跨域服务联合实现单点登录和联合退出。

OAuth 2.0协议特有的与用户交互、由用户显式对特定资源访问进行授权的过程使得基于该协议的跨域资源/服务访问控制十分灵活，是细粒度的、用户可知可控的，并可随时增加、修改和撤销授权。

2.2 同域服务联合

同域环境中各服务间的彼此调用协作也可视为服务联合的一种，由于各服务处于同一个信任域/安全域，服务联合的建立与访问控制都可根据本地策略灵活进行，本节仅对同域环境中基于OIDC的各服务身份认证方案进行描述。

即使处于同一个信任域，各服务同样可能具有互不相同的底层安全基础设施，且同域的特殊条件使得一致的身份验证策略和可靠的身份验证框架十分必要。耶鲁大学提出的CAS(central authentication service) 是解决此问题的经典协议。以下针对内部实现有IDP的企业和组织给出了基于OIDC的解决方法。

图 3展示了同域服务联合的典型场景，用户在使用服务C2时，C3、C4由于间接被调用而需要验证用户身份。引入2.1节的基于OIDC会话管理无疑可以解决问题，但基于同一安全域中各服务间基本的信任关系可以更简便地传递可验证的用户身份信息。域C使用本域中的OP/IDP进行用户的统一认证，用户首次访问C2服务时，C2引导用户前往本域的ODP处进行身份认证，在成功通过身份认证后获得ID Token；C2在之后请求C3、C4服务时携带该ID Token作为可认证用户身份标识；C3、C4接收到ID Token后，通过ID Token信息及其有效性验证结果即可获知用户身份及用户通过了身份认证这一事实。

该方法通过使用IDP统一了同域身份认证，并借助ID Token在同域服务之间传递了用户身份认证信息，该信息可验证(无法伪造)。值得注意的是，该方法以同域服务不会泄露ID Token这一假设为安全基础。

2.3 公共服务联合

跨域条件下的公共服务联合由于没有用户这一角色的参与，故不存在单点登录和联合退出问题，授权流程为OAuth 2.0协议授权模式的客户端模式。如图 4所示，A域的服务A4需要使用B域的公共服务B2。服务联合建立时，A4在B2处注册并得到自身身份标识与认证凭据，典型地，此处的凭据为一个公私钥对，私钥A4持有，公钥由B2保存。A4在需要使用B2服务时，针对待访问资源/服务发起授权请求，并在请求中携带私钥对该请求的数字签名；B2收到授权请求并成功验证签名信息后，分发Access Token给A4作为授权结果；A4通过在之后的请求中携带该Access Token来使用B2提供的服务。

3 一个智能制造社会化协同案例

船舶与海洋装备制造是高端制造业的典型代表，具有整体长周期、单件少批量、离散制造与局部流程制造的混合形态特征。智能制造的全制造服务周期^[11]涵盖了从研发设计到运维服务的全过程。在船舶与海洋装备的制造过程中，服务环节众多，其流程如图 5所示。

海洋装备制造流程中的各服务环节由多个企业提供，参与制造流程的不同企业构成临时服务于某个项目任务的VO。装备制造流程主要包括设计服务、总装服务和制造分包服务，其社会化协作的趋势是：提供总体设计CAD(computer-aided design)、工艺设计CAPP(computer-aided process planning)服务的各个企业之间联合构成独立的VO共享彼此的设计智慧；提供分段制造与配套装备服务的不同企业在总装集成企业的任务驱动下依据工艺设计交付相应的配套中间产品。在总装制造环节和分段制造环节中，企业资源计划ERP(enterprise resource planning)、产品生命周期管理PLM(product lifecycle management)、供应链管理SCM(supply chain management)、客户关系管理CRM(customer relationship management)、制造执行系统MES(manufacturing execution system)、数控机床网络DNC(distributed numerical control)以及其他内部服务形成纵向紧耦合集成。

上述案例涉及的VO服务联合如图 6所示。

位于域G的总装集成企业ERP服务通过调用本域内PLM、CRM、SCM及外域的CAD、CAPP等服务驱动整个制造流程，对外提供船舶与海洋设备制造服务，用户(甲方)通过访问域 G的服务来实时了解并操控制造流程。流程中的总体设计环节、工艺设计环节分别由域 B提供的CAD服务和域F提供的CAPP服务负责。域G的ERP服务根据设计结果，调用域 H、I、J的MES服务完成部分分段制造与配套设备业务，再基于外域和本域(总装集成企业也可能负责部分中间产品的制造)的分段制造与配套产品进行最终的总装集成。

在图 6所示的VO服务联合场景中，域 G、H、I、J中都存在同域服务联合，比如域 H中MES与DNC服务通过彼此调用以对外提供分段制造与配套设备服务；跨域的服务联合更是普遍存在。

用户通过域G启动的VO服务联合装备制造流程及相应的服务联合类型描述如下，根据服务联合类型即可采用第2节给出的相应认证与授权方案。

1) 域 G的ERP服务调用域 B的CAD设计服务，对应图中步骤1)，属跨域服务联合，使用2.1节的跨域服务联合认证授权方案；

2) 域 B的CAD服务调用域 A、C相同行业的CAD服务，获取其相关设计经验，形成总体设计图纸，属于跨域服务联合；

3) 域 F的CAPP服务调用域 B的CAD服务获得总体设计图纸用于工艺设计服务本身，对应步骤2)，属跨域服务联合；

4) 域F的CAPP服务共享域 D、E的工艺设计，形成工艺设计图纸，属于跨域服务联合；

5) 域 G的ERP服务调用域 F的CAPP服务获得工艺设计图纸，对应步骤3)，属跨域服务联合；

6) 域 G的ERP服务根据工艺设计图纸，调用自身的MES、DNC等服务(同域服务联合)和域 H、I、J的MES服务(对应步骤4)，属跨域服务联合)实现装备的分段制造；

7) 最后，域 G根据分段制造的中间件完成设备的总装集成，提供给用户。

需要说明的是，出于避免重复劳动和降低成本的考虑，域 B与同样提供CAD服务的域 A、C以某种约定的机制组成独立的VO以实现复用设计文件，共享彼此经验、技术等智慧成果。这种相同行业构成的VO，通过跨域服务联合进行智慧成果或生产能力的分享是一种典型的社会化协作，避免了信息孤岛的出现和生产能力的局限，为VO成员带来了更大的价值回报。

4 结论

本文基于VO服务联合安全需求及OAuth 2.0、OpenID Connect协议，设计了VO服务联合安全方案，详细描述了跨域服务联合、同域服务联合与公共服务联合的实现流程，并通过船舶与海洋装备制造的同域及跨域协同案例进行了具体应用过程说明。方案具有开放与实用的特点。

在此方案基础上还需要进一步研究是：

1) 基于OpenID Connect协议的认证过程获得ID Token可能会直接或间接暴露用户身份相关的敏感信息。对VO服务联合中的OpenID Providers而言，隐私保护(privacy protection)意味着不能在ID Token和Access Token中暴露用户ID及其他个人身份信息PII(personally identifiable information)。其提供的OpenID也应为PPID(pairwise pseudonymous identifier)，从而消除不同域获得的用户身份标识的关联。

2) 在服务联合实现后，需要建立服务间的合理付费机制，有助于提高虚拟企业在智能制造协同中的制造服务分享动机。