无侵入式Web平台集成自动认证机制的设计与实现.pdf

Microcomputer Applications Vol.39,No.8,2023文章编号：10 0 7-7 57 X(2023)08-0005-04无侵入式Web平台集成自动认证机制的设计与实现基金项目微型电脑应用2 0 2 3年第39 卷第8 期邵瑛，徐斌?（1.上海电子信息职业技术学院，电子技术与工程学院，上海2 0 1411；2.上海诺基亚贝尔，固网事业部，上海2 0 12 0 6）摘要：单点登录是多Web平台集成时常用的统一认证方案，它对Web平台是侵入式的，需要各Web平台在代码上的支持，不适合已经成型的系统。针对该问题提出了一种无侵入式的第三方Web平台自动认证机制，该机制基于私有域名，采用认证代理适配器实现后端Web平台的域名绑定及登录认证。为实现认证过程中私有域名的自动解析，提出基于Web的动态私有域名机制，避免客户端需频繁手动修改Hosts文件来解析私有域名的问题。提出的无侵入式自动认证机制具有广泛的实用性。关键词：Web平台；域名；自动认证；认证代理适配器中图分类号：TP393.0文献标志码：ADesign and Implementation of Non-intrusive Automatic AuthenticationMechanism in Web Platform IntegrationSHAOYing,XU Bin?(1.School of Electronic Technology and Engineering,Shanghai Technical Institute of Electronics and Information,Shanghai 20141l,China;2.Fix Network Business Group,Nokia Shanghai Bell,Shanghai 201206,China)Abstract:Single sign on(SSO)is a common unified authentication scheme used in the integration of multiple Web platforms,itis intrusive to the Web platform,needs the code support,and is not suitable for the formed system.To solve this problem,anon-intrusive automatic authentication mechanism for the third-party Web management platform is proposed.Based on the pri-vate domain name,the mechanism uses the authentication proxy adapter to realize the domain name binding and login authenti-cation of the back-end Web platform.In order to realize the automatic resolution of private domain name in the authenticationprocess,a dynamic private domain name mechanism based on Web is proposed,which avoids the problem that the client needsto frequently manually modify the Hosts file to resolve the private domain name.The proposed non-intrusive authenticationmechanism has wide practicability.Key words:Web platform;domain name;automatic authentication;authentication proxy adapterWeb平台1Web平台20引言一个大的系统里面集成来自不同供应商的多种业务服务，为了给最终用户一个良好的体验，这些业务服务人口需要从图1分散的独立业务服务管理框架转向图2 的统一业务集成平台框架。在图2 的后端业务Web平台的认证上，通常采用基于OAuth、O p e n I D、LD A P等的单点认证(SSO)1-2。但单点认证需要后端业务服务Web平台在最初开发时就进行支持，对于已经开发完成但不支持SSO的系统就需要进行二次开发。针对此问题，本文设计一种基于Web的动态私有域名，提出一种无侵入式的自动认证机制。该机制有效地解决了自动认证和私有域名在客户端的自动解析问题，并通过在HTTP协议中增加新的HTTPHeader来实现私有域名在Web服务器和客户端之间的共享。1989年，HTTPL31协议诞生。2 0 15年发布了HTTP/2L4-5。H T T P/2 充分考虑了现今互联网的现状：宽带、移动、基金项目：中国高校产学研科创新基金（2 0 2 0 HYB01003）作者简介：邵瑛（197 2 一），女，硕士，副教授、高级工程师，研究方向为计算机网络与机器学习；徐斌（197 4一），男，博士，杰出技术专家，研究方向为大数据分析和计算机网络。Web平台n用户（浏览器）图1独立业务服务管理框架安全。在高度兼容HTTP/1.1的同时，在性能改善方面做了很大努力。2 0 18 年，互联网标准化组织IETF提议将“HTTPoverQUIC”更名为“HTTP/3”并获得批准，HTTP/3正式进人了标准化制定阶段。5图4认证代理适配器Microcomputer Applications Vol.39,No.8,2023Web平台n1统一业务集成管理平台用户（浏览器）图2 统一业务集成平台管理框架1天无侵入式Web平台集成自动认证方案的设计Web平台认证信息的验证通常都是采用会话（session）或类似的机制来实现的，会话信息保存在客户端（如浏览器）中，是基于Cookie形式来保存的，包含会话ID、域（Domain）、路径（Path)等信息。系统成功认证后，Web服务器与客户端（浏览器)之间会保存一个相同的会话ID，以后每次客户端（浏览器）向服务器发送Domain和Path下的HTTP请求时，都会带上对应会话ID，W e b 服务器会根据接收到的会话ID来判断该用户是否已经认证。因此，用户认证时采用的域名必须与后续业务操作时所访问的域名一致，否则存在跨域问题，无法进行认证。1.1基于认证代理适配器的自动认证方案设计为使用户认证时采用的域名与后续业务操作时的域名一致，同时使第三方后端业务服务Web平台完全透明、无侵人，本文设计了认证代理适配器的自动认证方案。该方案在统一业务集成平台框架（图2)中引人一个参与方：HTTP反向代理，并针对各种不同的后台业务服务Web平台在HT-TP反向代理中实现认证代理适配器，适配器包括两部分：配置脚本和登录脚本。配置脚本用来动态绑定私有域名和IP，在配置过程中使用；认证脚本在认证过程中使用。该方案的认证流程如图3所示（HTTP反向代理采用nginx）。具体步骤如下。后端业务服务Web管理平台自动认证流程客户端（浏览器）统一业务集成平台代理(nginx)Web管理平台请求业务入口页面（2)返回业务入口页面3）请求后端业务认证代理适配器登录脚本并传入认证信息(4)返回后端业务认证代理适配器登录脚本N（）根据认证信息，自动向后端业务Web管理平台发起认证（8）返回成功认证信息(9）后续其他业务操作图3后端业务服务Web平台自动认证流程基金项目Web平台1Web平台2微型电脑应用2 0 2 3年第39 卷第8 期（1）用户首先通过客户端（浏览器）从统一业务集成平台访问相关页面，完成登录脚本页面链接。（2）统一业务集成平台返回相关页面内容。（3）用户请求登录脚本，同时提交认证所需的参数信息。该适配器脚本保存在HTTP反向代理nginx的/static目录下。（4）H T T P反向代理nginx根据（3）中传送的认证信息配置好登录脚本并返回给用户。（5）认证代理适配器登录脚本自动向HTTP反向代理nginx发起认证请求。（6）H T T P反向代理nginx将请求转给后端业务服务Web平台。（7）后端业务服务Web平台向HTTP反向代理nginx返回认证成功。（8）H T T P反向代理nginx向客户端返回成功信息。（9）认证成功后转人后续业务操作。在认证前，认证代理适配器登录脚本和后端业务服务Web平台IP在动态配置过程中已经被认证代理适配器配置脚本绑定到同一域名下，因此，在上面的认证过程中就不存在跨域问题。图4是一个认证代理适配器登录脚本的实现及其配置脚本绑定的私有域名信息。认证代理适配器(1)认证代理适配器配置脚本配置的域名绑定信息(nginx配置)upstreampccserverserver135.251.214.123:443;servertlisten443ssl;server_name ;sslon;ssl_certificatessl/server.crt;ssl.certificate_key ssl/server.key;add_headerAccess-Control-Allow-Origin*;add_header Access-Control-Allow-MethodsGET,POST;location/allowall;proxy_pass https:/pccserver;location/static/(root/data;HTTP反向后端业务服务(6)自动发起认证请求（7）返回成功认证信息(2)认证代理适配器登录脚本，存放在nignix的/static目录下$(document).ready(functionO!var storage-window.locaiStorage;var params-window.location.search.substring(1);var afterEqual=params.split(-);var paramstr-decodeURIComponent(afterEqual1);varobj-JSON.parse(paramstr);s.ajax(t.type:POsT,url:obj.server+/pccj/_security_check:data:jusername-fobj.username+&j_password-+objpassword,complete:function(xhr,textstatus,err)(storageWebApplicationUser-username:+obj.username+,roles:03;sleep(500).then(0=Window.location.href-obj.location;3;function sleep(time);return new Promise(resolve)=setTimeout(resolve,time);在图3中，由于认证代理适配器登录脚本及后台业务服务Web平台绑定的域名都是私有域名，无法通过公用DNS进行解析，因此需要设计一种方案让客户端可以对私有域名进行解析。6Microcomputer Applications Vol.39,No.8,2023目前常规方案是提前在系统的Hosts文件中配置好私有域名。但在该方案中，虽然通过修改Hosts中的配置可以实现私有域名的自动解析，但当后台业务服务Web平台绑定的域名或对应的IP发生变化时,Hosts中的配置需要做相应的调整。Hosts在客户端无法自动与服务器端保持一致，因此，需要设计一种新机制来解决该问题。1.2基于Web的动态私有域名机制1.2.1扩展巴科斯一诺尔范式 6-7 互联网技术规范经常需要定义一种格式化语法并能自由地使用作者认为是有用的任何符号。扩展巴科斯-诺尔范式（ABNF)已经在许多互联网规范中流行。这样的规范包括电子邮件规范RFC733和之后的RFC822，这些规范已经成为定义扩展巴科斯-诺尔范式的公共引用。一个ABNF规范是一些推导规则的集合，书写为规则=定义；注释CRLF其中：“规则”是不区分大小写的非最终符号；“定义”由定义该规则的一系列符号组成；“注释”用于记录；“CRLF”（回车、换行）用来结束。规则名字不区分大小写：，和都提及同一个规则。规则名字由1个字母以及后续的多个字母、数字和连字符（减号)组成。用尖括号(“)包围，规则名并不是必需的，但是它们可以用来界定规则名，以便识别出规则名。1.2.2基于Web的动态私有域名机制设计为了解决需要不断地更新本地Hosts文件来配置私有域名的问题，需要设计一种基于Web的动态私有域名机制。该机制涉及HTTP协议的扩展，需要浏览器和Web服务器端配合实现，可以通过向IETF提交RFC草案来建议普适性实现 8-9。机制实现方案如下。1）W e b 服务器端设计Web服务器端需要实现动态的配置信息。（1）私有域名与IP的对应关系，可以同时配置多条对应关系。（2）私有域名的作用范围，目前定义为两个层次：应用级（application）和页面级（page）。应用级表示在整个Web应用范围内有效，页面级表示在当页面有效。（3）私有域名有效期的单位为秒。2）H T T P协议Header的扩展服务器与客户端之间通过扩展一个新的Header:Pri-vate-dns来实现私有域名配置信息传递。该Header定义采用ENBF中的语法 10 1。Private-dns=“Private-dns“reg_ name=IPv4address*(,reg_name=IPv4address)“,age=age-value;“scope“=”(application|page)“reg-name=*（u n r e s e r v e d /p c t-e n c o d e d /s u b-d e-lims)IPv4address=1*digit“,1*digit“1*digit“1*digitage-value=1*digit3）客户端的设计客户端对Private-dns处理机制如下。基金项目（1）客户端私有域名信息的存储如果从服务器返回的HTTPHeader中包含Private-dns信息，需要将这些信息保存到本地存储中，信息结构采用JSON格式:privatednsarray=itemi,item2.item,item=“url:relativeurl,privatedns:Private-dns)如果Private-dns中的scope是application，则relativeurl设置为“/”,否则设置为实际的相对url。（2）客户端Private-dns的应用为了在客户端自动解析私有域名，客户端在域名解析上需要增加一个私有域名解析流程。当用户点击一个私有域名链接，客户端首先查询本地存储，检查是否存在基于当前page的Private-dns记录，如果记录存在，在有效期内，且该记录中包含该私有域名的IP信息，则将该私有域名设置到HTTP请求头中的Host。同时，利用IPv4Address进行TCP层的连接，如果不存在基于当前page的记录，则查是否存在基于当前application的记录，如果记录存在，在有效期内，且该记录中包含该私有域名的IP信息，则将该私有域名设置到HTTP请求头中的Host。同时利用IPv4Address进行TCP层的连接，否则按照正常的域名解析流程进行后续的HTTP请求。其域名解析的有限状态机如图5所示。返回HTTP响应准备域名解析Private-dns域名解析成功(域名解析成功通过缓冲区域成（等待通过缓名解析成功人冲区域名解析）通过DNS域名缓冲区域名解析成功解析失败等待通过DNS域名解析DNS域名+解析失败DNS域名解析失败图5包含Private-dns机制客户端的域名解析2自动认证机制的实现及性能分析为了验证该自动登录机制，特别是实现基于Web的动态私有域名机制，需要在Web服务器端和浏览器端对代码进行修改配合实现。2.1Web服务器端的实现Web服务器端采用SpringBoot中的Tomcat作为Web服务器。相对于常规代码，只需要在系统每次返回前端页面时，加人下面的代码：String pdns=getPDnsFromDB();response.addHead-er(Private-dns,pdns);该代码的逻辑就是读取Private-dns的配置信息，然后通过设置HTTP的协议头Private-dns，将私有域名信息返回到前端。7微型电脑应用2 0 2 3年第39 卷第8 期新页面到达发起HTTP请求立Private-dns域名解析失败DNS域名解析失败处理Microcomputer Applications Vol.39,No.8,20232.2Web浏览器端的实现浏览器端通过对Chorme（版本号7 4.0.37 0 4.1）源码进行修改重新编译来实现。修改涉及两部分：HTTPHeader中Private-dns 的提取与存储、私有域名的解析。下面是私有域名解析部分的入口代码。Chorme的域名解析DNS的人口函数是HostResolver-Manager:Resolve,它首先调用HostCache:Lookup在缓存中查找域名的IP信息，私有域名解析代码就添加在Lookup中最前面：const std:pair*HostCache:Lookup(const Key&.key,base:Time-Ticks now,bool ignore_secure)(DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);Auto*pdnsresult=LookupPrivateDnsFields（k e y,now);if(caching_is_disabled()return nullptr;auto*result=LookupInternallgnoringFields（k e y,now,ignore_secure);if(!pdnsresult)result=pdnsresult;if(!result)return nullptr;当进行域名解析时，首先调用私有域名解析函数进行解析，如果解析成功，则替换后面Cache中的查找结果，否则保留Cache中的查找结果，继续按照以前的逻辑处理。2.3性能分析机制中涉及了HTTP协议的扩展，客户端发起请求时，需要对私有域名进行解析，客户端有一定的时间开销，通过测试，每次私有域名的解析时间开销不足10 ns，因此对用户的感知没有任何影响；HTTP协议头中增加的Private-dns也占用一定的带宽。根据Google对网页大小的平均统计，网页平均大小约为32 0 KB。图6 基于此统计分析了不同私有域名数目对网络负荷的影响。根据分析结果，即使1次HTTP应答消息中带10 0 个私有域名，网络负荷只增加了1%左右，对整个系统基本没有影响。1.51.0F0.501网络负荷增加情况/%图6 Private-dns头对网络负荷的影响2.4项目中的应用本文提出的无侵入式自动认证机制已经在实际的项目“全光网络集中管理服务系统”中得到了成功应用。系统实现了3种不同Web平台的认证代理适配器（3种Web平台均不支持SSO，无法集成到单点登录的系统中）：管理OLT的557 1PCC平台的认证代理适配器；管理ONU/基金项目ONT（供应商1)的CoCP平台的认证代理适配器；管理ONU/ONT（供应商2）的CSP平台的认证代理适配器。每种认证代理适配器都可以通过私有域名及基于Web的动态私有域名机制支持多台Web平台的自动认证。系统中浏览器端采用定制版Chorme（版本7 4.0.37 0 4.1)以支持基于Web的动态私有域名机制。对于其他版本的Chorme和其他类型浏览器，需要提前在客户端的Hosts文件中进行私有域名的配置。“全光网络集中管理服务系统”正被部署在多个企业中。3总结为了解决集成第三方业务服务Web平台自动认证问题，本文设计了一种无侵入式的自动认证机制，并在实际的项目中得到了很好的应用。该机制相对于SSO具有更广泛的实用性。该机制中提出的基于Web的动态私有域名机制通过扩展RFC2616HTTP协议头定义一个新的Header：Priavate-dns，有效地解决了私有域名的动态解析问题，并在实际的项目中得到了很好的应用。参考文献1沈桐，王勇，刘俊艳.基于OAuth2.0,OpenIDConnect和UMA的用户认证授权系统架构 J.软件，2 0 17，38(11):160-167.2 王群，李馥娟。一种基于单点登录的实验室统一身份认证方案 J.实验室技术与管理，2 0 2 0（5）：2 19-2 2 3.3李康，陈清华，卢金星.HTTP协议研究综述 J.信息系统工程，2 0 2 1(5）：12 6-12 9.4FIELDING R,GETTYS J,MOGUL J,et al.Hy-pertext Transfer Protocol-HTTP/1.1 JJ.IETFRFC2616,June 1999,https:/www.rfc-editor.org/rfc/rfc2616.txt.5BELSHE M,PEON R,THOMSON ED M.Hyper-text Transfer Protocol Version 2（H T T P/2)JJ.IETF RFC7540,May 2015,https:/www.rfc-editor.org/rfc/rfc7540.txt.6 CROCKER ED D,OVERELL P.Augmented BNFfor Syntax Specifications:ABNFJ.I ET G FRFC5234,January 2008,https:/www.rfc-editor.org/rfc/rfc5234.txt.7 黄文锋，李晓伟，霍占强.基于EBNF和二次爬取策略的XSS漏洞检测技术 JI.计算机应用研究，2 0 19（8）：2458-2463.8FLANAGAN H.RFC Style Guide J.IETFRFC2223,https:/www.rfc-editor.org/rfc/rfc2223.510微型电脑应用2 0 2 3年第39 卷第8 期100txt.9 BRADNER S.The Internet Standards Process-Revi-sion-3JJ.IETF RFC2026,https:/www.rfc-editor.org/rfc/rfc3986.txt.10BERNERS LEE T,FIELDING R,MASINTER L.Uniform Resource Identifier(URI):Generic SyntaxJ.IETF RFC3986,https:/www.rfc-editor.org/rfc/rfc3986.txt.（收稿日期：2 0 2 1-12-0 3）8