在本文的身份认证模式提出之前, 先提出当前适用于该云平台的一般中心化身份认证模式。一般中心化身份认证模式需要用户注册一个新的账户, 即新的身份信息, 或是通过第三方的身份信息进行授权登录。其简要认证步骤如下:

(1) 用户在云平台以新注册的身份或第三方授权的身份登录云平台;

(2) 云平台通过匹配自身的注册信息库验证是否是有效认证, 或向第三方发送信息并接收认证反馈, 如果验证失败, 返回步骤(1);

(3) 用户在云平台使用成员图书馆的资源, 根据成员图书馆Web站点之间互操作的安全访问协议, 通过令牌或其他单点登录身份验证手段, 登录到成员图书馆并获取相应权限;

(4) 重复步骤(3), 直到用户离开服务。

上述一般身份认证模式在逻辑上和实现上都较为简单, 技术也比较成熟。但缺点是用户仍然需要记忆不同图书馆中的身份信息, 还要额外记忆云平台新注册的身份信息。而且要实现各个成员馆之间的单点登录, 需要成员馆两两之间达成协议, 不利于成员馆数量的扩展。

基于第3节对支撑平台用户身份认证问题的分析, 下面尝试提出一种自上而下的中心化身份认证方案:

(1) 需要一个隐式或显式的全局身份;

(2) 需要一个自治身份对全局身份的映射关系;

(3) 如何部署这一映射关系的验证逻辑。

使用关系代数表达各个身份间的联系。设S_C为云平台的独立账号。在“ 国家公共文化数字支撑平台” 的建设方案中, 实际考虑采集的数据有: 用户ID、真实姓名、用户密码、密码忘记问题、密码忘记答案、性别、E-mail、电话、地址、身份证号、民族、职业、学历、访问权限、访问日志等^[11]。示例如下:

S_C(用户ID, 用户口令, 身份证号, 身份证识别码, R_C)

其中, R_C是其他相关信息, 又由于身份证号的敏感性, 用全局唯一的身份识别码替代身份证号来区别是否是同一用户。同理, 对于用户在某一图书馆Ln的身份S_Ln可表示为:

S_Ln(用户ID, 用户口令, R_Ln)

实体图书馆的读者证办理需要提供有效证件, 包括居民户口簿、身份证、临时身份证、军官证、护照等。图书馆的网站鼓励读者进行实名制注册, 其中国家图书馆将居民身份证作为唯一的实名制身份证明。因此图书馆的读者可以划分为以下三种:

(1) 物理卡持有者, 必定是实名制用户, 但使用的有效证件不一定是身份证;

(2) 网络实名制用户, 使用的有效证件也不一定是身份证;

(3) 网络非实名制用户。

根据是否使用身份证作为实名制的证件, 可以将上述分类等价地划分为:

(1) 身份证实名制用户;

(2) 非身份证实名制用户;

(3) 非实名制用户。

对于第一种等价的图书馆身份类型, 记为:

S° _Ln(用户ID, 用户口令, 身份证号, R° _Ln)

第二种和第三种等价身份类型记为:

S° ° _Ln(用户ID, 用户口令, R° ° _Ln)

给出三个身份的转换如下:

T₁(局部身份的用户ID, 身份识别码, 局部身份的地址)
T₂(身份识别码, 身份证号)
T₃(身份识别码* , 身份识别码)

其中, T₁用以保存局部身份的映射; T₂用以利用现有的身份证实名制注册资源以达到统一身份的目的; T₃用以在用户通过不同途径获得多个身份识别码时, 用一个新的身份识别码唯一标识。

用户在登录云平台时可以有两个选择: 显示地注册一个云服务账号。注册时鼓励实名制注册, 即提供身份证号码, 并采集用户的电子邮箱和用户名, 作为登录的备选, 以及一个口令; 用户不注册新的账号。用在现有图书馆的任何一个账号登录云服务。

不管选择哪种登录方式, 云平台在第一次登录时都会生成一个身份S_C(用户ID, 用户口令, 身份证号(可空), 身份识别码, R_C)。当用户选择两种登录方式时, 将产生两个身份识别码, 如果用户提供统一身份所需的材料, 则会产生一个新的身份识别码。这样, 用户可以通过各个图书馆的实名制注册或自己指定本人的其他身份账号达到统一身份的目的。

目前各个图书馆身份认证是高度自治的。与OpenID使用URI唯一标识一个用户身份不同, 图书馆的局部身份在全局下并不能保证唯一性, 也就是说, 图书馆A和图书馆B可能存在相同的读者号N, 但是这个读者号对应的是两个不同的读者。但实际进行验证时使用的信息至少有用户的局部身份和局部身份对应的口令, 即使局部身份的ID相同, 口令却极有可能不同。只是在极微小的概率下会发生用同一局部身份和口令可以登录两个以上的账户。对于这种情况, 云服务要求用户再提供额外的信息, 如局部身份注册地点, 进而消除二义性。

用户必须有一个全局身份来统一各个局部身份所保存的用户信息, 这个身份笔者在之前已经讨论。用户可以拥有若干个局部身份, 这些局部身份与具体的服务提供者密切相关, 因为这些局部身份保存在服务提供者的身份管理服务器上。对于这些局部身份, 通过身份映射找到具体身份所在的服务器, 把认证的工作交给身份所在服务器处理, 而云端的全局服务器只负责将身份进行转化。

除“ 一服务对应一身份” 的传统情景外, 可以将多重身份使用情景归纳为以下三类:

(1) 用户以局部身份Ia登录云平台C;

(2) 用户以全局身份登录私有服务Sa;

(3) 用户以局部身份Ia登录私有服务Sb。

对于第二种情况, 局部身份Ia是全局身份的超集, 用全局身份进行局部身份的逆映射, 就可以转化为以局部身份Ia登录私有服务Sa的情况。对于第三种情况, 局部身份Ia以第一种情况隐式地登录云平台获得全局身份, 再将全局身份逆映射到局部身份Ib上, 就可以通过Ib登录私有服务Sb。因此只需要考虑第一种情况的映射问题。

本文提出的身份认证模式架构如图1所示。身份认证模式架构可以实现以成员馆局部身份登录云服务。图1中全局身份目录服务器用于保存4.2节所述的云平台的注册身份S_C、身份转换表T₁、T₂、T₃和已经登录过的成员馆局部身份所在馆的网络地址或歧义标识等信息; 二级身份目录服务器负责底层目录服务器和全局身份目录服务器的中转工作, 保存成员馆的地址信息、歧义的身份来源、成员馆新身份创建的处理(判断新身份是否与局部身份存在歧义); 底层身份目录服务器即成员馆的身份信息服务器。登录流程如下:

图1

	Figure Option ViewDownloadNew Window
	图1 文化数字资源云服务的多级身份认证模式

(1) 用户以该局部身份及其口令登录云服务(必要时提供注册身份的成员馆);

(2) 云服务通过协议和标准化语言向IDaaS云服务请求身份验证;

(3) IDaaS云服务将身份信息发给全局身份目录服务器;

(4) 首次登录时, 全局身份目录服务器判定这一身份没有登录过, 并将这个局部身份传到二级身份目录服务器; 非首次登录时, 全局身份目录服务器判定这一身份登录过, 若存在身份来源馆, 将馆址和身份传给二级身份目录服务器, 否则一定存在歧义标识, 用户需要提供来源馆的消歧义信息;

(5) IDaaS云向二级身份目录服务器提交身份验证请求;

(6) 首次登录时, 二级身份目录服务器准备向所有成员馆进行广播, 将所有底层身份目录服务器地址交给IDaaS云; 非首次登录时, 二级身份目录服务器根据全局目录服务器传来的来源馆信息, 查找具体身份来源的成员馆网络地址交给IDaaS云;

(7) IDaaS云向底层身份目录服务器发送身份验证请求;

(8) 底层身份目录服务器确认与当前云服务存在服务使用关系, 并且存在这个身份ID和身份证明, 于是返回确认信息, 否则返回验证失败;

(9) 首次登录时, IDaaS将验证结果和提供验证的成员图书馆提交给当前云服务, 当IDaaS收到且仅收到1条确认信息时, 全局身份目录服务器记录该身份和成员馆信息, 登录成功; 当IDaaS收到多于1条确认信息时, 全局身份目录服务器记录该身份和歧义标识, 返回步骤(1), 并进行非首次登录流程; 当IDaaS收到0条确认信息时, 返回步骤(1), 进行首次登录流程。非首次登录时, IDaaS将验证结果交给当前云服务, 当IDaaS收到且仅收到一条确认信息时, 登录成功; 否则, 登录失败, 返回步骤(1), 进行非首次登录流程。

由于多个成员馆之间可能存在相同ID的用户, 所以局部身份一定存在歧义, 上述流程的消歧是可行的。用户提供的信息是有序对< 局部身份的用户ID, 局部身份的口令> , IDaaS返回多条确认信息, 当且仅当在多个成员馆中存在相同ID和口令的有序对。当这一情况发生时, IDaaS要求用户在成员馆列表中选择注册该身份的馆; 当用户提交身份信息后, 生成新的有序三元组< 局部身份的用户ID, 局部身份的口令, 成员馆ID> , 直接根据成员馆ID寻址。该有序三元组在没有输入错误的情况下一定是唯一的, 因为每个成员馆中的用户ID都是唯一的, 即在全局下< 局部身份的用户ID, 成员馆ID> 唯一。

当用户同意服务使用协议, 并且或显式或隐式地生成一个全局身份标识后, 云服务可以自动地向各个底层身份目录服务器查询用户的局部身份, 在后台完成自动的身份统一, 而不必再以局部身份登录时才进行统一。这就意味着这种身份认证模式存在两个优点:

(1) 用户无需先选择所属图书馆, 只需直接录入本人的局部身份, 减轻用户的操作和记忆负担;

(2) 当有新馆加入成员馆时, 不必与已经存在的成员馆进行身份信息的沟通, 而只需与云服务商沟通。

在减轻用户负担的同时, 这种身份认证模式的弊端主要表现在服务器端的负担:

(1) 用户在云服务商输入自己的身份标识和口令时, 云服务网站必须给予明确的身份登录提示, 否则, 就会给用户带来困惑;

(2) 首次认证效率低下: 假定有M个成员馆, 每个成员馆平均有N万用户信息, 总计MN万用户。由于该认证模式的广播方式, 因此, 当所有用户首次访问云服务时, 都需要在M个成员馆对应的底层身份目录服务器上以遍历方式进行认证。这意味着, 每个底层服务器都要经历MN万次的认证, 只有N万次是有效认证, 其余(MN-N)万次的认证均为无效认证, 有效认证比例仅为1/M, 即成员馆越多, 认证效率越低。

该身份认证模式与信息服务、身份验证的操作、身份验证的流程控制分开, 与Shibboleth开源系统^[18]有着很多共同点。但Shibboleth系统采用的是松耦合协作方式, 而本模式采用的是中心化联邦协作方式, 并结合了松耦合协作方式。也就是说Shibboleth并没有采用一个全局身份去统一各个子系统中的身份, 而是直接将身份认证交给子系统处理。

这种中心化(自上而下)身份认证模式的可行性分析主要从逻辑和效率两个方面说明:

(1) 逻辑上是可行的。该云服务的用户在注册身份时被予以两种选择: 与一般网络信息服务相似的注册方式, 即提供一个新的账户和口令以及其他必要信息, 即显式地注册全局身份; 不注册, 通过已有成员图书馆的身份信息进行登录, 而在云端隐式地生成全局身份, 即隐式地注册全局身份。无论是哪种注册方式, 只要用户提供其身份证号就可以通过成员馆身份信息的整合对用户信息进行统一管理。在登录时, 使用云服务账号(局部身份之一)进行登录与一般网络信息服务, 使用云服务账户之外的局部身份信息进行的首次登录区别于以后的登录: 首次登录通过向成员馆广播的方式找到该局部身份信息所在的馆(见4.4节), 如果无身份歧义, 则登录并记录馆址, 否则首次和以后登录时都要额外提供成员馆信息; 以后的登录通过馆址直接访问, 无需再进行广播。

(2) 效率上还需进一步的试验和讨论。效率上的问题主要集中在首次认证的效率和用户局部身份信息的歧义消除上。首次认证的效率为1/M, M为成员馆数量, M越大, 计算资源的浪费就越大。但由于服务采取记忆的策略, 即记录该局部身份ID的成员馆馆址, 所以在以后的登录中回避了这一效率低下的问题, 后期的效率将趋于1。因此只要服务器能承受云平台开通初期的登录压力, 测试就能够稳定地进行身份验证。用户的局部信息产生歧义, 在登录时, 表现为有序对 < 局部身份的用户ID, 局部身份的口令> 重复。通常情况下, 这是同一人在不同成员馆使用相同的注册信息, 在极少数情况下会存在多人使用相同的注册信息。如果是同一人, 可以使用全局身份进行统一, 否则就必须提供注册馆信息。但“ 通常情况” 和“ 极少数情况” 并没有确切的统计数据支持, 获得这些统计数据也是可行性试验的重点。

除了逻辑和效率以外, 还存在安全性和用户隐私保护问题。特别是在首次登录广播时, 要比常规的登录方法危险。成员馆的信息系统安全性遵循木桶原理, 只要有一家成员馆的信息系统存在安全隐患, 就意味着所有成员馆的用户信息都需要承担这一安全隐患。