光纤工程中基于OpenID的统一认证系统设计与实现

胡共由，胡捷程，凌力

0 引言

随着云计算的应用与普及，单点登录(single sign-on,SSO)越来越为人们所需求，也成为了信息化和网络扩展的必然要求。单点登录，即用户在一个登陆点进行身份验证后，可以借此对一组与之相关的网络应用服务进行访问，而不必在一个个依次去登录各自的用户认证。OpenID 协议便是以此为目的诞生的网络服务认证协议，用户将URI 作为用户标识，OpenID 身份提供商作为验证方(OpenID provider,OP)，网络应用服务提供商作为依赖方(Relying Party,RP)，只需进行一次登录验证，无需重复注册和登录认证便可请求任何依赖此OP的网络应用服务，其开放、自由、离散的标准化机制使之成为了炙手可热的单点登录和数据共享方面的应用协议。现代化的企业，无论是大型企业还是中小型企业，都迫切需要在单点登录与用户认证方面有长足的改善，以适应新的企业管理系统在RFID 技术与云计算技术的大热潮中与时俱进，从根本上保证安全性并提高运营效率。

本文从一个光线工程管理项目入手，设计并实现了一个在企业运作中能够普遍适用的基于OpenID的统一认证系统，对实际应用中的分等级认证、多重身份登录、用户角色授权等诸多问题提出了可行的解决方案，为云计算中企业用户的统一认证提供参考。

1 OpenID 机制

OpenID 是一种广泛应用于云计算中的去中心化身份认证技术。OpenID 以统一的身份标识(如URI 等)作为唯一识别的用户身份标记，用户可以随意的选择一个OpenID 服务网站或者自行建立一个提供这样服务的网站，只要完成一次注册，每个用户所对应的唯一的URI 将通过一定程序编程生成唯一的认证标识，口令则被安全的存储在一个OpenID 服务器中，用户请求某个RP的应用服务时RP 会向该OP 进行用户合法性认证，因此用户无需进行多次注册便可请求各个RP的应用服务。OpenID 身份验证由OP 完成，支持该OP的RP 通过OpenID 协议委托OP 来实现用户身份信息的确认，OpenID 账户信息在互联网范围内是共享的并存放在数据云中。下面简要介绍OpenID 认证过程，OpenID协议流程操作步骤为，如图1所示：

图1：OpenID 流程

1)终端用户访问OP 进行用户注册。

2)注册成功返回注册信息。

3)用户提交详细个人资料，并可在注册OP的数据空间进行个性化配置。

4)用户提交应用站点服务请求。

5)应用站点返还给用户一个其支持的OpenID 登录页面。

6)用户进行OpenID 认证。

7)RP 向OP 请求身份认证。

8)引导到用户登录界面。

9)登录。

10)完成认证。

11)用户相当于用RP的注册帐号成功进行登录。

同传统的两种认证机制独立验证和私有第三方验证相比较而言，OpenID 认证机制很好的解决了用户标识的唯一性问题，使得用户跳出了重复注册、多次输入密码等一系列的重复操作，大大减轻了用户的认证负担，经过近些年的快速发展，OpenID 技术标准日趋成熟，其简单、开放、共享、便捷的特性使得在各种领域都用广大的应用空间，对于如何开发出更具有商业应用价值的认证模型成为了很多人关心的问题。

2 光纤工程系统简介

光纤工程是为了光纤监测和系统维护，基于物联网和云计算而建立的光纤管理系统，用于对光纤进行线路施工、工程维护等工作，实现智能化、可维护、易考核的高效工程管理系统，并与光纤监测系统协同工作，形成完善的一体化系统。系统工作流程，如下图所示：

图2：光纤工程系统

光纤工程工作流程可分为3 类：

1)初始准备阶段。施工人员为机房、机架和光纤打上RFID 标签。

2)工程实施阶段。工程师设计程序并生成智能工单，施工人员下载工单并依次对光纤进行连接工作。

3)维护工作阶段。光纤的修复、更换、改接、拆除等操作。

在本项目中，按人员职能可分为项目管理员、工程设计师和施工人员，项目管理员对某个具体项目进行物流和人事管理，工程设计师负责对项目进行软件编程和程序设计，施工人员则执行工程实施工作。

3 基于OpenID 统一身份认证

现在诸如像中国移动等公司的光纤管理基本就是外包给一些专门用来提供光纤管理服务的公司进行操作，那么在这些外包公司中工作人员用各自的ID 登录到系统站点时所拥有的权限必然是不一样的，有的人可能还拥有多重身份，比如A 在同X 公司的合作项目中既是工程设计师又是施工人员，他的ID 登录到提供应用服务的站点时应该如何去区别他的身份并授予相应权限？而既然是专门提供光纤管理服务的公司，其同时与多家企业进行项目合作时需要设置一个统一认证，这样项目中的工作人员只要用同一个账户登录便可访问企业对于各个合作公司的数据空间和应用站点，这样既可以减轻员工的操作负担同时也保证了工作效率。对此，我们将OpenID 应用到该系统中，设计并实现了一个用于对其用户进行统一身份认证的模型。

3.1 系统结构

作为是向工作人员所提供的统一认证，那么其登录形式要尽可能的多样化，满足用户可以在公司、工地甚至在家里都可以用手机、平板电脑、笔记本电脑、台式机等等终端进行登录，同时我们自行建立一台OP 服务器并将所有用户数据保存在本地的后台数据库中，具体系统结构，如图3所示：

图3：基于OpenID 统一认证系统结构

用户可使用手机、PAD、PC 等进行登录，在公司内部可用WiFi 连接到OP 服务器，这样既快捷又可以保证数据安全性，而在施工地点或者其他非公司网络覆盖的区域可以用GSM、3G、互联网登录，OP 服务器和数据库都由公司自己提供，项目中我们用一台安装有Apache的服务器作为OP，并用SQL server 2008r2 作为后台数据库保存OpenID用户数据，OP 通过互联网与各个合作公司的RP 站点进行用户认证工作，本系统的统一认证主要实现分等级认证、多重身份登录、用户角色授权等功能的设计，下文逐一进行介绍。

3.2 分级认证

对于用户而言，同一个ID 应该可以具有不同的操作权限因为有时候过多的操作权限不仅没有必要，反而会影响数据安全性。比如项目管理员会习惯性的每天登录帐号查看各项目进度，那么这里系统只需赋予他的ID 阅读权限即可，如果他的ID 和口令被人截取那也只有阅读权限这样会降低损失，而当他回到公司有一个较为安全的网络环境时，那么他想对工程实施计划进行修改等操作时便可以用更高的权限进行登录，系统赋予他的ID 修改、删除、插入等权限。这样因不同场合和工作需求来进行分级登录认证在光纤工程中是完全有必要的，于是我们对用户登录进行了以下三类等级认证的设置。

1.匿名认证。有区别于一些网站上游客登录的性质，匿名认证验证了登录ID的合法性，具体的操作，如图4所示：

图4：匿名认证和用户认证

用户对RP 站点1 请求匿名认证时，OP 只需要返回给RP 一个随机码来表明该用户拥有此登录ID，说明已经通过认证，但仅仅是通过认证而用户没有任何的阅读、插入、删除等具体操作权限，当然系统可以添加显示一些比如该ID所拥有的权限等级等比较基本的信息。匿名登录最大的作用在于任何一个用户都可以用来验证自己拥有的ID 是否合法，项目管理员、工程设计师和施工人员都可以用此方法来查看自己ID 在其他合作公司RP 站点的合法性，以及查看自己在系统中的权限等级，而系统同样可以统计登录次数方便RP 站点依此进行统计分析。

2.用户认证。相比于匿名认证，用户认证则是在认证用户ID 合法性的基础上对用户ID的权限进行了识别和授权，这里主要是指用户ID 拥有阅读权限。具体操作如图4所示，当用户就RP 站点2 请求用户认证时，OP 将登录用户的ID提供给RP，RP 可以根据此唯一标识为用户提供阅读权限级别的网络服务。于是项目管理员可以查看项目总体进度和项目实施计划，工程设计师可以查看施工进度，施工人员可以查看自己负责区域的施工情况等等。这种情况下OP 必须得向RP 提供用户ID 以及其他可用信息，RP 依此来对用户提供网络服务。

3.内容认证。 相比于用户认证，内容认证加入了从用户到RP的数据交互，这种认证不仅要识别用户ID的合法性，又要对用户进行高级别权限的授权，同时还要保证用户向所RP 提交数据的完整性、可靠性、安全性，防止RP 对数据进行修改，我们对协议进行如下改进，如图5所示：

图5：内容认证

用户端将消息t 做公钥加密c=E(k,t)发送到OP 服务器，其中用户和RP 拥有私钥可以进行解密，OP 将密文c 同用户身份i 做私钥加密T=Ek(c,i)并将T 发送给RP，这样任何用户可以在OP 查询到T，用户将密文c 发送给RP，RP 拥有密钥并解密得消息t 进行发布，任何有相关管理权限的用户在知道了是由哪个用户修改了数据的情况下，只需查询并解密OP 中的T 即可判断RP 发布的消息t 是否被篡改，篡改与否直接影响RP的信用度，过低的信用度无疑会失去公司企业对该站点的信任。在实际应用中，项目管理员A 若想修改项目实施计划，他用ID 进行内容登录并进行修改操作，同时作为合作公司的管理员B 对项目计划进行查看时，在知道了是由A 修改了计划的情况下，可以在OP 中找到T，解密即可判断RP 发布的数据是否被第三方恶意修改。

对于用户来说采用相对较低的认证等级进行登录可以放心的进行各种操作，比如工程设计师进行匿名登录查看自己ID的合法性和拥有权限等级，那么他不必过于担心自己的个人信息等会被截取和泄漏，而采用相对较高的认证等级进行登录时则要注意登录环境的安全性，比如在网吧或者其他信息不安全的场所不要进行登录。在OpenID 中RP 对用户服务的不同定位决定了同一个ID 可能拥有不同的操作权限，而越高的权限意味着越高的安全要求和风险，那么在用户身份认证中加入用户分级认证是合理而且必须的，通过项目我们也验证了其在实际应用中的可行性和实效性。

3.3 多重身份

对于光纤工程中的工作人员而言可能同时兼任着不同的职位，在不同的职业场合要进行不同的工作，比如C 既是工程设计师又是工程施工人员，有时候要进行系统和程序的设计工作有时候又要去工地进行工程实施，进入一家合作企业站点时是项目管理员进入另一家合作企业的站点时是程序设计师，那么他的ID 登录时必然要有多种的身份识别，于是同一ID的多重身份认证在企业统一认证平台中是必不可少的。

当同一ID 在不同服务网站拥有多重身份和权限时，再用原来的OpenID 进行身份认证以及请求网络服务时会遇到问题。我们举例来说明：工程设计师H 担任同B 公司合作中项目经理一职，H 在B 公司的云服务站点注册且拥有自己的账户Y，同时B 公司授予权限，假设他使用OpenID 身份X 登录到B的服务器，那么此时他拥有B 站点中对某些数据进行阅读、修改等权限，但这是他在B 服务器中的数据空间是OpenID 身份X 对应的操作权限而不是他最初注册到B 站点时的账户Y的数据空间，因此他无法打开Y的账户管理页面、操作记录、个人资料、最新通知等等数据，如果他忘记了Y的登录信息和密码那么他将无法找回Y的数据资源，这一定程度会影响用户的判断和操作，更会对用户更新自己账户信息带来极大的不便。

为了解决这一问题，我们在原有的基础上对协议进行一定改进，如图6所示：

图6：多重身份认证

操作步骤为：

1.终端用户申请RP 网络服务。

2.RP 请求身份认证。

3.用户通过OpenID 进行登录认证。

4.OP 将用户标志性信息发送给RP。

5.RP通过比较注册用户与OP发送过来用户资料的相似度得出此用户合法并将信息发送给OP。

6.RP 同用户进行一个挑战响应。

7.挑战响应通过，通知OP。

8.用户登录RP，权限和数据空间同在RP 注册的帐号完全一致。

由于是企业云服务统一认证，用户在注册的时候会比一般性的RP 站点要严谨的多，单位、职业、用户名、注册邮箱、联系电话等信息组合在一起几乎可以形成一个唯一化的用户身份，同样在OpenID 服务器中在用户注册时会保存以上几种甚至更多的用户个性信息，同一个用户在不同的站点注册时的身份信息应该有高度的相似性，通过OpenID 服务器与RP 站点的用户信息做比较就可以得出是否是当前登录用户。按OpenID 协议，用户、OP 以及RP 之间拥有足够的信任度，用户信息详细保存在OP 和RP 上，当用户通过OP登录某个RP 时OP 将用户特征性的详细信息发送给RP，RP 比较用户信息相似度，当相似度达到某个阈值，在本项目中满足单位、职业、用户名、注册邮箱相同，且其余信息80%相同时，RP 发送个用户一个挑战响应，向用户提问用其注册时的安全问题，若用户通过此挑战响应则系统判定用户身份登录有效，OP 服务器登录到实际的RP 账户中。如果以上认证失败则按照原来的OpenID 协议，用户只能登录OP 服务器账户。回到刚才的登录问题中，如果执行改进后的协议，工程师H 用OP 服务器登录B 站点，只要是合法身份，他在OP 和站点B的用户信息肯定符合系统判定阈值，只要通过系统挑战响应便可登录到站点B的注册账户Y 中去，大大减轻了用户操作负担并使得用户在云服务站点之间来回登录转换身份提供了有效的解决办法。

3.4 角色授权

角色是本系统中的核心要素，当用户登录时并不是登录ID 获得了权限而是用户ID 放入到了某个角色中获得了该角色所拥有的权限。系统管理员可以按照企业的各自要求定义拥有不同权限的角色，甚至可以具体到单个数据的权限，这使得授权非常灵活和多样。本项目中的角色定义，如图7所示：

图7：角色定义

光纤工程外包公司定义了A、B、C3 种角色，角色A拥有对员工信息、项目计划进行查询和修改的权限，同时可以查看项目进度，角色B 拥有制作、查询、修改所有工单的权限，角色C 拥有对工单3 和其进度进行查询的权限。各员工ID 进行登录时的操作，如图8所示：

图8：用户角色授权

本项目中各工作人员职能定位为：项目管理员拥有对其负责项目的所有数据进行修改的权限，工程设计师有对项目工单进行添加、修改和删除权限，施工人员只有对自身工作进行查询的权限。那么只要在数据库定义3 类角色，角色A拥有项目最高权限，包括对所有数据的操作，角色B 拥有对所有工单数据操作权限，角色C 拥有对工作内容的阅读权限。这样，当上述3 种职位的人用各自ID 登录时，OP会根据系统判定对ID 进行识别并分别将项目管理员、工程设计师、施工人员的ID 添加到角色A、角色B、角色C 中，这3 种职业便拥有了各自应该具备的操作权限，当然这种操作权限不仅仅局限于本公司站点，因为是基于OpenID的统一认证登录，那么在其他依赖此OP的RP 应用站点也拥有相应的角色与之对应，这里不一一说明了。而当此项目完成，公司间的合作结束而需要收回访问RP 站点的权限时只需要删除数据库中的角色A、B、C 即可。

通过定义角色来授予用户权限是基于OpenID 统一认证系统中减轻授权工作量的有效手段，比如有10 个项目管理员、50 个工程设计师、500 个施工人员，如果按照传统的用户授权方式需要对这560 个用户一一进行配置，而且如果其中的权限发生变更重新配置会非常麻烦，而用角色授权的方法只需要定义如上3 种角色A、B、C 便一次性解决了授权问题，不仅减少了管理强度也降低了多次的重复工作而引起的误操作。

4 总结

由于云计算以及SaaS 模式等技术的日渐火热，统一认证的重要性再一次被验证，本文从一个光纤工程项目入手，提出了企业共享数据云并提供云服务的设想，重点设计了基于OpenID 协议的统一身份认证系统，通过对比传统的认证方式发现了基于OpenID 协议认证方式的优势与不足，同时在一定层度上予以了改进，可以说是为云计算发展到企业云服务的创新性研究。该系统经光纤工程项目验证，可以有效提高用户操作效率并确保数据安全性，用户可以因环境信息安全性的差异选择合适认证等级进行登录，同一用户又可以以多重身份进行认证，系统则按照定义角色来配置登录用户的操作权限，减轻了用户和系统的操作负担、提高了项目管理的运转效率，是企业云服务中有效的统一认证系统。

毕竟云服务还没有非常的成熟，在企业方面的实际应用还不十分广泛，我们将在已有的基础上继续围绕云计算、SaaS 模式、RFID 技术等热门技术对企业统一认证平台进行进一步的分析、设计与实现，将统一认证和数据安全上升到单个应用服务中去，为企业云服务的实际应用提供有效参考。

[1]岳小均.基于云计算的统一身份认证与管理平台研究与实现[D].电子科技大学硕士论文,2011.

[2]李馥娟.单点登录技术分析及在数字图书馆中的应用[J].图书情报工作,2009(21):111.

[3]杨浩泉,皮冰锋,彭酋,杨华,邹纲,王主龙.基于OpenID的可兼容身份认证系统设计与实现[J].计算机应用与软件,2012,29(4):281-284,292.

[4]David Recordon,Drummond Reed.OpenID 2.0:a platform for user-centric identity management.[J]ACM,Nov,2006.

[5]Yoshisato Takeda,Seiichi Kondo,Yasuhide Kitayama,Massashi Torato,Tsuyoshi Motegi.Avoidance fo performance bottlenecks caused by HTTP redirect in identity management protocols.[J]ACM,Nov,2006.