DB36_T 1181-2019 移动政务服务应用接入技术规范(高清无水印-可复制）

1、ICS 35.080L 07DB36江西省地方标准DB36/T 11812019移动政务服务应用接入技术规范Technical specification of mobile application access for government service2019 - 12 - 13 发布2019 - 12 - 13 实施江西省市场监督管理局发 布DB36/T 11812019I 目次前言II引言III1 范围12 规范性引用文件13 术语和定义14 移动政务服务应用接入概述15 移动政务服务应用接入流程36 移动政务服务应用技术要求57 移动政务服务应用审核要求78 移动政务服务应用管理要

2、求89 移动政务服务应用运营要求8附录 A（规范性附录） 用户信息交互示例及说明9附录 B（规范性附录） 动账消息推送示例及说明10附录 C（规范性附录） 数据埋点示例及说明11附录 D（规范性附录） 敏感信息脱敏处理规则14 DB36/T 11812019前言本标准按照GB/T 1.1-2009给出的规则编制。 本标准由江西省发展和改革委员会提出并归口。本标准起草单位：江西省信息中心。 本标准主要起草人：金俊平、吴俐、孙杨、李新华、黄振、侯文刚、张弩、葛敏捷。 IIDB36/T 11812019IIIAdministrator2020-01-17 09:03:33订修改为：定引言根据国务院办

3、公厅进一步深化“互联网+政务服务”推进政务服务“一网、一门、一次”改革实施方案（国办发201845号）要求，为进一步提升江西政务服务网服务能力， 着力打造移动政务服务系统，以实现“一网通办”移动应用，特制订此标准。 本标准规定了全省移动政务服务应用接入技术规范，要求各地各部门在对接全省移动政务服务系统过程中，实现统一访问入口，统一开发标准，统一上架流程，统一运维管理。DB36/T 11812019DB36/T 11812019移动政务服务应用接入技术规范范围本标准规定了移动政务服务应用系统接入的流程、技术要求、审核要求、管理要求和运营要求等内容。 本标准适用于全省移动政务服务系统建设。 规范性

4、引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 ZWFWC0103-2018 国家政务服务平台政务服务移动端建设要求 国务院办公厅关于印发“互联网+政务服务”技术体系建设指南的通知(国办函2016108号) 进一步深化“互联网+政务服务”推进政务服务“一网、一门、一次”改革实施方案(国办发201845号) 术语和定义下列术语和定义适用于本文件。 3.1移动政务服务系统 the mobile platform of government service地方和部门政务服务移动应用

5、及资源的汇聚接入系统，面向自然人、法人和其他组织提供全省政务服务查询、咨询和移动办事服务的入口。 3.2政务服务应用 the application of government service由地方或部门为自然人、法人和其他组织提供各类网上政务服务。 移动政务服务应用接入概述总则移动政务服务系统将不同机构单位、不同标准、不同渠道的各类政务服务、公共服务事项经过聚合、转换，形成统一标准、统一管理、统一展现的应用单元或服务接口。 系统总体架构参考国办函2016108号文件中的平台技术架构，移动政务系统总体技术架构设计全面符合全省移动政务服务接入的统一技术规范、安全和运维保障规范，规划总体技术架构由

6、基础设施层、政务服务资源层、应用支撑层以及访问层组成。总体构架示意图请见图1。 1DB36/T 11812019DB36/T 11812019 PAGE 8 PAGE 9 图1 总体构架示意图系统功能定位功能定位功能定位主要有以下几个方面： 1） 统一服务入口、提升用户体验；多地区个性化服务集约化管理；为移动政务应用建立统一对接、统一运维、统一推广；为政务大数据共享、融合、汇聚和挖掘打下基础；打造全省移动政务服务建设的开放生态体系。系统组成移动政务服务系统，由应用接口入驻子系统、应用开放子系统、事项管理子系统、微门户管理子系统、运营数据统计子系统组成，各系统主要情况如下： 接口入驻子系统：全局

7、监管移动政务服务系统所有政务服务应用的原始业务接口，实时监控接口运行状况，对出现异常的接口及时预警；应用开放子系统：提供丰富的开发组件，对应用的整个生命周期进行流程化管理，统一发布各个终端；事项管理子系统：通过对接全省在线办事、在线预约等事项服务，自动化生成办事表单，动态管理前端事项展示；微门户管理子系统：对移动端的页面样式、栏目结构、发布信息进行管理和变更控制；运营数据统计子系统：通过业务埋点实现对接入服务的 PV、UV、服务点击量、业务办理量等关键数据进行实时统计。功能服务功能服务应满足以下几个方面： 提供标准的接口入驻方式，输出统一域名、统一接口地址；提供标准的应用开发组件，保证应用体验

8、在移动端获得一致的体验效果；制定标准的应用测试、应用上下架、应用运维管理流程，确保应用质量可靠；提供安全、统一的用户信息、用户认证、业务信息等敏感数据交互服务；提供统一的数据运营监控服务，打造以人为中心的服务体验。应用类型移动政务服务应用分为需身份信息类应用和完全开放类应用。 需身份信息类应用要求按照统一对接原则要求，经过用户授权，统一获取移动政务服务系统用户信息。 完全开放类应用无需调用用户信息，遵循统一接入流程对接各子系统。 对接方式对接方式如下： 接口对接：提供业务接口，按要求进行服务应用开发；数据对接：提供业务数据，先开发业务接口后再进行服务应用开发。认证方式要求所有政务服务应用均应统

9、一采用移动政务服务系统的用户认证体系。包括个人/法人用户的登录、注册、刷脸认证等服务能力。所有应用涉及到登录、注册、刷脸认证等功能时，应直接调用移动政务服务系统相关界面，操作完成后跳转回本应用。 移动政务服务应用接入流程接入流程总览移动政务服务应用接入总体流程分为应用接入、应用开发、应用审核发布三个步骤，移动政务服务应用对接流程图见图2。 图2 移动政务服务应用对接流程图数据交换地方和部门数据要求经过省或市数据统一交换系统，统一处理跨网业务数据。 接口入驻概述按照移动政务服务系统统一对接原则，要求各地各部门将政务服务应用接口注册移动政务服务系统接口入驻子系统，对政务服务应用接口进行统一管理，统

10、一监控，并输出标准的接口地址。 接口入驻流程接口入驻流程如下： 申请账号：联系移动政务服务系统项目组获取相关账号；接口注册：根据业务需求，对接口进行封装改造后注册接口入驻子系统；提交审核：将注册完成的接口提交审核，审核通过后即可获取标准地址；测试使用：对获取的地址进行测试后，使用接口进行服务开发。应用入驻概述按照移动政务服务系统统一对接原则，要求各地各部门将政务服务应用前端页面上传移动政务服务系统应用开放子系统，对政务服务应用前端进行统一管理，统一测试，并输出标准的页面地址。 应用入驻流程应用入驻流程如下： 申请账号：联系移动政务服务系统项目组获取相关账号；应用开发：根据技术对接标准，使用前端

11、语言开发业务服务；应用上传：将开发好的应用压缩后上传应用开放子系统；应用测试：测试人员根据审核要求进行业务测试，测试通过即可生成标准的访问地址。移动政务服务应用技术要求用户对接要求移动政务服务应用接入建立安全可靠的信息交互流程，具体流程见图3，流程如下： 1） 用户授权：需身份信息类服务通过移动政务服务系统申请；授权验证：移动政务服务系统对用户授权请求进行验证；加密用户信息：移动政务服务系统对授权用户信息进行 SM4 加密；分发授权信息：将已加密的授权用户信息分发给请求方；解密用户信息：请求方使用移动政务服务系统解密方式进行解密操作。图3 移动政务服务应用接入基于票据获取用户信息交互图Admi

12、nistrator2020-01-17 09:01:25删除多余标号接口对接要求接口规范注册地方和部门要求对接口自行封装，应用接口通过接口入驻子系统进行接口注册和管理。 接口注册时，地方和部门应填写接入应用的源接口地址和功能描述，以及相关请求参数与返回参数。若注册的接口属于查询类，要求提供有效的测试参数。 请求方式支持 get、post 和 webservice 方式，参数支持 string 和integer 类型。 接口数据缓存为保障应用的并发能力和承载高访问量，对非必需实时请求类接口，要求对接口做缓存处理，缓存清除周期最短为 24h。 接口安全鉴权通过移动政务服务系统进行互联网交互的应用要

13、求进行接口访问鉴权，支持两种鉴权模式： 1） 安全鉴权：请求签名机制，签名算法采用 SM2，双方以安全方式存储接口鉴权密钥；白名单鉴权：接口白名单，要求地方和部门与移动政务系统开放对接的域名，需加入访问白名单后方可连通；应用接口请求所需的接口鉴权密钥需要加密存储，并且不可在前端页面进行调用。接口鉴权密钥是在接口入驻子系统与业务接口交互时进行鉴权使用。接口功能自测接口提交审核前，要求地方和部门使用接口入驻子系统的在线测试工具进行自测， 确认业务接口正常接通，确定接口返回数据格式； 接口需要满足高并发的要求，并发数应达到 1000+，响应时长不超过 2s； 接口需要满足安全性的要求，涉及敏感信息应

14、进行加密或脱敏处理。 应用开发要求应用安全提交政务服务应用使用 HTML5 语言开发，业务接口要求调用接口入驻子系统返回的标准。 接口地址和 key 码，在应用审核的时候，会进行匹配审核。 部门和地方要求按照标准流程进行移动政务服务应用开发，杜绝外链直接挂载。 应用代码需封装成压缩包（.zip）提交应用开放子系统。 底部统一标识移动政务服务应用的所有页面底部都需注明“本服务由某某单位提供”。 图形验证码使用为了阻止攻击者使用自动工具和程序连续恶意提交表单尝试登录、查询等行为，接入服务应用涉及到表单提交时，建议加入验证码，尤其不要求用户登录的服务应用必须在提交表单时加入图形验证码， 以降低被暴力

15、查询获取大批量接入单位业务数据的可能。若验证码影响用户体验，地方和部门可以自行决定多少次提交表单后再显示验证码。对于图形验证码的技术要求建议如下： 验证码在设计上必须要考虑到相关安全因素，以免能被轻易地破解，常见的方式是增加背景干扰元素；验证码在一次使用后要求立即失效，新的请求需要重新生成验证码，防止验证码多次有效。表单输入校验地方和部门开发服务应用时必须对用户产生的输入内容进行校验，不能完全依赖于移动政务服务系统前端校验，必须使用服务端代码对输入数据进行最终校验。前端校验只能作为辅助手段，减少前端和服务端的信息交互次数。一旦发现数据不合法，应该告知用户输入非法并且建议用户纠正输入。一方面Ad

16、ministrator2020-01-17 09:00:10。Administrator2020-01-17 09:00:20。是为了提升用户体验，另一方面是为了防止攻击者通过输入进行 SQL 注入、XSS 攻击等恶意行为。 应用模拟测试要求地方和部门联系移动政务服务系统支撑人员，申请开发者工具使用权限； 要求地方和部门应用审核前，对应用进行全面测试，确保页面正常访问； 应用中所有涉及用户基本信息、证照信息、办事信息等系统已有数据，要求自动关联数据， 避免让用户二次输入。用户信息获取需按要求调用全省统一用户交互接口见附录 A。 消息推送要求为解决业务向用户实时精准推送各类信息、服务的需求，移动

17、政务服务系统向接入的政务服务应用提供了一套标准的业务消息接口，政务服务应用要求调用标准消息通知接口，以消息推送形式及时通知到移动政务服务系统，在移动政务服务系统个人中心或消息模块等地方展示，让用户在最短时间触达消息。地方和部门要求调用全省统一的消息通知推送接口进行消息推送见附录B。 业务埋点要求为进行数据分析，并作为地方和部门考核依据，要求应用开发时做好相应埋点设置，做好与运营数据统计子系统的对接工作，保证数据真实可用。地方和部门要求调用全省统一的数据埋点接口见附录C 中表C.1、C.2、C.3，数据埋点方式包括新用户授权埋点、用户访问埋点、应用访问埋点。 安全保护要求关键信息脱敏个人敏感信息

18、包括身份证号、手机号、固定电话号码、邮箱、家庭住址等，所有应用都必须妥善做好敏感信息保护。对自动获取的敏感信息，进行信息脱敏处理，做好前端展现控制，不在用户端各交互界面传递未脱敏的用户信息，防止因账号被盗用造成个人敏感信息泄露。信息脱敏要求参照全省统一的脱敏规则见附录D。 身份真实性控制对于涉及用户隐私的，应仅限高级实名用户进入；如有必要，还可发起实时人脸识别身份验证。 用户授权确认任何需调用用户个人隐私信息的服务，必须弹出个人信息使用授权提示，说明提取信息类型和用途， 经用户确认后方可使用。 支持 HTTPS为防止网络劫持、页面挂码等风险，要求移动政务服务系统支持HTTPS访问，接入单位在开

19、发应用服务时需保证页面加载的所有资源协议支持HTTPS访问。 移动政务服务应用审核要求原则测试人员根据测试审核要求对应用可用性、兼容性、安全性进行全方位审核，审核通过后方可发布上架。 页面要求为保证移动政务服务应用在上架后用户体验一致，地方和部门需按照要求统一页面设计，增强用户体验。具体页面要求如下： 兼容性高，能够适配不同手机机型；交互提示友好，不同使用场景下要有对应的使用引导； 结构布局清晰，相同类型业务数据要归类展示，不同业务数据展示方式要有区分； 体验流畅高效，页面数据展示延时最长不超过 2s，页面切换平滑流畅； 操作层级简化，完整流程页面跳转最多不超过 5 层，精简页面流程设计。 质

20、量要求服务风格统一。要求所有接入的应用保持文字大小统一、图片尺寸统一、按钮规格统一、表单样式统一、加载效果统一、底部落款统一。服务功能完善。要求所有接入的应用在保障业务流程可行的前提下，事项办理流程简化，使用正确控件，对接用户信息，避免二次登录，确保结果数据展示无误。服务体验流畅。要求所有接入的应用考虑设备兼容苹果系统和安卓系统，避免出现空白页、错链、死链等情况。服务性能稳定。要求所有接入的应用接口响应快，能抗压抗并发，并准备故障解决预案。服务安全可靠。要求所有接入的应用经过安全加密、数据脱敏等处理，并支持 HTTPS 安全协议。移动政务服务应用管理要求为保障移动政务服务系统不断接入更加优质的

21、服务，参考国办发201845号文件调动社会资源力量，鼓励开展第三方便民服务应用。加强政务新媒体监管，提升服务水平。为保证线上服务运行稳定， 要求地方和部门建立专门的运维保障小组，按照ZWFWC0103-2018中的8.3.5处，应用上下线管理包括政务服务应用兼容性、可用性、安全性及压力测试，并对上线的政务服务应用进行统一监控，定期对服务功能、用户体验、系统稳定、数据安全等方面对应用进行细化检查，应做到如下几点： 要求地方和部门做好信息可用性监控；要求地方和部门做好服务稳定性检查；要求地方和部门对访问数据做好监测和分析；要求地方和部门制定可行的故障应急预案；要求地方和部门做好政务服务应用版本管理

22、。移动政务服务应用运营要求为努力提升移动政务服务系统知晓度和使用率，打造江西移动政务服务品牌，不断增强群众的获得感和幸福感，地方和部门应切实做好内容维护和线上线下宣传推广工作，应做到如下几点： 要求地方和部门全面开展宣传报道工作；要求地方和部门切实加强线下推广工作；要求地方和部门认真做好线上推广工作；要求地方和部门积极组织策划推广活动。附 录 A（规范性附录）用户信息交互示例及说明A.1 获取用户信息接口根据票据获取用户信息接口见表A.1。 表A.1 获取用户信息接口服务名称 getUserInfoByTicket (获取用户信息) 方法说明 使用移动端传递的票据信息,通过校验后台的秘钥对和应

23、用 id 进行用户信息授权使用，返回加密用户信息。 请求方法 POST URL 地址 https:/API_ROOT/interfaces/getUserInfoByTicket.do 访问权限 合法接入电子证照系统的应用程序 请求参数 参数名 必选 类型范围 说明 ticket 是 String 移动端生成票据 appid 是 String 分配给每个应用的唯一 id 返回结果 succ 是 String 返回码(true 为成功，false 为失败) data 是 String 具体信息 succ: true, token: composeB7ee886d452524098b7c2d9c4

24、9a5bbX37, data: headpic: /images/partner/T1e8XeXbdcXXXXXXXX, nickname: , 返回示例 email: 152*8584, cert_type: 0, name: 赖*, userid: 208811263318*, cardid: 362532*1714, mobile: 152*8584 DB36/T 11812019DB36/T 1181201910 11 附 录 B（规范性附录）动账消息推送示例及说明B.1 动账消息推送接口动账消息推送接口见表B.1。 表B.1 动账消息推送接口服务名称 addMsgInfos (消息批

25、量推送) 方法说明 该接口是实现动账提醒支付宝城服批量消息推送， 传入参数 Params 为数组，数组内每个对象为 json。请求方法 POST URL 地址 https:/API_ROOT/interfaces/dztxMsgInfo/addMsgInfos.do 访问权限 合法推送业务动账消息 请求参数 参数名 必选 类型范围 说明 params bizType 是 String 业务类型(目前定义：1 表示公积金 2 表示电子证照 后续业务类型增加再进行定义) bizName 是 String 推送业务名称（如：省直公积金汇缴分配） bizCode 是 String 业务编码(在监测系统

26、系统进行消息推送业务配置后大汉提供) name 是 String 姓名 idcard 是 String 身份证号码 cityCode 是 String 城市编号（如南昌市：360100） opreateDate是 String 操作日期（示例：2018-05-06） bdje 否 String 变动金额（示例：1999.9）（公积金业务推送填写） zzmc 否 String 证照名称（电子证照业务推送填写） expireDate 否 String 过期时间（示例：2018-05-06）（电子证照业务推送填写） 返回结果 succ - String 返回码(true 为成功，false 为失败)

27、 msg - String 数据入库结果 sendMsg - String 数据推送结果 返回示例 msg:数据插入成功,succ:true,sendMsg:支付宝推送成功 附 录 C（规范性附录） 数据埋点示例及说明用户访问埋点接口用户访问埋点接口见表C.1。 表C.1 用户访问埋点接口服务名称 userView (用户访问埋点) 方法说明 该接口是实现对用户访问进行埋点记录， 传入参数 params 为对象 json。 请求方法 POST URL 地址 https:/API_ROOT/interface/buryPointUser/userView.do 请求参数 参数名 必选 类型范围

28、说明 params userid 是 String 支付宝用户标识 name 是 String 姓名 idCard 是 String 身份证号码 isPopulariz e 是 String 是否来自推广活动（0 否 1 是） popId 否 String 推广标识（isPopularize 为 1 时填写） location 是 String 所在分厅名称（示例：赣州市） isAllCount 是 String 是否计入访问量（0 否 1 是） position 是 String 当前定位行政区划编码（示例：360100） remark 是 String 当前所在分厅行政区划编码（示例：36

29、0700） 返回结果 succ - Boolean 返回码(true 为成功，false 为失败) msg - String 结果消息 返回示例 msg:用户访问量埋点成功,succ:true 应用访问埋点接口DB36/T 11812019DB36/T 118120191 PAGE 4 13 应用访问埋点接口见表C.2。 表C.2 应用访问埋点接口服务名称 insert(应用访问埋点) 方法说明 该接口是实现对应用访问进行埋点记录， 传入参数 params 为对象 json。 请求方法 POST URL 地址 https:/API_ROOT/interface/buryPointApplica

30、tion/insert.do 请求参数 参数名 必选 类型范围 说明 parmas name 是 String 姓名 idCard 是 String 身份证号码 isPopulariz e 是 String 是否来自推广活动（0 否 1 是） popId 否 String 推广标识（isPopularize 为 1 时填写） appName 是 String 应用名称 parId 是 String 应用所属栏目 id appRemark 是 String 应用唯一标识 location 是 String 当前所在分厅名称（示例：赣州市） appType 是 String 应用类型（1 普通应用 2 电子证照 3 服务专区）remark 是 String 当前所在分厅行政区划编码（示例：360700） 返回结果 succ - Boolean 返回码(true 为成功，false 为失败) msg - String 结果消息 返回示例 msg:成功,succ:true 新用户授权埋点接口新用户授权埋点接口见表C.3。 表C.3 新用户授权埋点接口服务名称 userAut