DB36 T 1181-2019 移动政务服务应用接入技术规范.pdf

《DB36 T 1181-2019 移动政务服务应用接入技术规范.pdf》由会员分享，可在线阅读，更多相关《DB36 T 1181-2019 移动政务服务应用接入技术规范.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.080 L 07 DB36 江 西 省 地 方 标 准 DB36/T 11812019 移动政务服务应用接入技术规范 Technical specification of mobile application access for government service 2019 - 12 - 13发布 2019 - 12 - 13实施 江西省市场监督管理局 发布 DB36/T 11812019 I 目 次 前言.II 引言.III 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 移动政务服务应用接入概述.1 5 移动政务服务应用接入流程.3 6 移动政务服务应用技术

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

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

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

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

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

7、管理子系统、微门户管理子系 统、运营数据统计子系统组成，各系统主要情况如下： 1） 接口入驻子系统：全局监管移动政务服务系统所有政务服务应用的原始业务接口，实时监控接 口运行状况，对出现异常的接口及时预警； 2） 应用开放子系统：提供丰富的开发组件，对应用的整个生命周期进行流程化管理，统一发布各 个终端； 3） 事项管理子系统：通过对接全省在线办事、在线预约等事项服务，自动化生成办事表单，动态 管理前端事项展示； 4） 微门户管理子系统：对移动端的页面样式、栏目结构、发布信息进行管理和变更控制； 5） 运营数据统计子系统：通过业务埋点实现对接入服务的PV、UV、服务点击量、业务办理量等 DB3

8、6/T 11812019 3 关键数据进行实时统计。 4.3.3 功能服务 功能服务应满足以下几个方面： 1） 提供标准的接口入驻方式，输出统一域名、统一接口地址； 2） 提供标准的应用开发组件，保证应用体验在移动端获得一致的体验效果； 3） 制定标准的应用测试、应用上下架、应用运维管理流程，确保应用质量可靠； 4） 提供安全、统一的用户信息、用户认证、业务信息等敏感数据交互服务； 5） 提供统一的数据运营监控服务，打造以人为中心的服务体验。 4.4 应用类型 4.4.1 移动政务服务应用分为需身份信息类应用和完全开放类应用。 4.4.2 需身份信息类应用要求按照统一对接原则要求，经过用户授权

9、，统一获取移动政务服务系统用 户信息。 4.4.3 完全开放类应用无需调用用户信息，遵循统一接入流程对接各子系统。 4.5 对接方式 对接方式如下： 1） 接口对接：提供业务接口，按要求进行服务应用开发； 2） 数据对接：提供业务数据，先开发业务接口后再进行服务应用开发。 4.6 认证方式 要求所有政务服务应用均应统一采用移动政务服务系统的用户认证体系。包括个人/法人用户的登 录、注册、刷脸认证等服务能力。所有应用涉及到登录、注册、刷脸认证等功能时，应直接调用移动政 务服务系统相关界面，操作完成后跳转回本应用。 5 移动政务服务应用接入流程 5.1 接入流程总览 移动政务服务应用接入总体流程分

10、为应用接入、应用开发、应用审核发布三个步骤，移动政务服务 应用对接流程图见图2。 DB36/T 11812019 4 图2 移动政务服务应用对接流程图 5.2 数据交换 地方和部门数据要求经过省或市数据统一交换系统，统一处理跨网业务数据。 5.3 接口入驻 5.3.1 概述 按照移动政务服务系统统一对接原则，要求各地各部门将政务服务应用接口注册移动政务服务系统 接口入驻子系统，对政务服务应用接口进行统一管理，统一监控，并输出标准的接口地址。 5.3.2 接口入驻流程 接口入驻流程如下： 1） 申请账号：联系移动政务服务系统项目组获取相关账号； 2） 接口注册：根据业务需求，对接口进行封装改造后

11、注册接口入驻子系统； 3） 提交审核：将注册完成的接口提交审核，审核通过后即可获取标准地址； 4） 测试使用：对获取的地址进行测试后，使用接口进行服务开发。 5.4 应用入驻 5.4.1 概述 按照移动政务服务系统统一对接原则，要求各地各部门将政务服务应用前端页面上传移动政务服务 系统应用开放子系统，对政务服务应用前端进行统一管理，统一测试，并输出标准的页面地址。 5.4.2 应用入驻流程 DB36/T 11812019 5 应用入驻流程如下： 1） 申请账号：联系移动政务服务系统项目组获取相关账号； 2） 应用开发：根据技术对接标准，使用前端语言开发业务服务； 3） 应用上传：将开发好的应用

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

13、交互图 DB36/T 11812019 6 6.2 接口对接要求 6.2.1 接口规范注册 6.2.1.1 地方和部门要求对接口自行封装，应用接口通过接口入驻子系统进行接口注册和管理。 6.2.1.2 接口注册时，地方和部门应填写接入应用的源接口地址和功能描述，以及相关请求参数与返 回参数。若注册的接口属于查询类，要求提供有效的测试参数。 6.2.1.3 请求方式支持get、post和webservice方式，参数支持string和integer类型。 6.2.2 接口数据缓存 为保障应用的并发能力和承载高访问量，对非必需实时请求类接口，要求对接口做缓存处理，缓存 清除周期最短为24h。 6.

14、2.3 接口安全鉴权 通过移动政务服务系统进行互联网交互的应用要求进行接口访问鉴权，支持两种鉴权模式： 1） 安全鉴权：请求签名机制，签名算法采用SM2，双方以安全方式存储接口鉴权密钥； 2） 白名单鉴权：接口白名单，要求地方和部门与移动政务系统开放对接的域名，需加入访问白名 单后方可连通； 3） 应用接口请求所需的接口鉴权密钥需要加密存储，并且不可在前端页面进行调用。接口鉴权密 钥是在接口入驻子系统与业务接口交互时进行鉴权使用。 6.2.4 接口功能自测 6.2.4.1 接口提交审核前，要求地方和部门使用接口入驻子系统的在线测试工具进行自测，6.2.4.2 确 认业务接口正常接通，确定接口返

15、回数据格式； 6.2.4.2 接口需要满足高并发的要求，并发数应达到1000+，响应时长不超过2s； 6.2.4.3 接口需要满足安全性的要求，涉及敏感信息应进行加密或脱敏处理。 6.3 应用开发要求 6.3.1 应用安全提交 6.3.1.1 政务服务应用使用HTML5语言开发，业务接口要求调用接口入驻子系统返回的标准。 6.3.1.2 接口地址和key码，在应用审核的时候，会进行匹配审核。 6.3.1.3 部门和地方要求按照标准流程进行移动政务服务应用开发，杜绝外链直接挂载。 6.3.1.4 应用代码需封装成压缩包（.zip）提交应用开放子系统。 6.3.2 底部统一标识 移动政务服务应用的

16、所有页面底部都需注明“本服务由某某单位提供”。 6.3.3 图形验证码使用 为了阻止攻击者使用自动工具和程序连续恶意提交表单尝试登录、查询等行为，接入服务应用涉及 到表单提交时，建议加入验证码，尤其不要求用户登录的服务应用必须在提交表单时加入图形验证码， 以降低被暴力查询获取大批量接入单位业务数据的可能。若验证码影响用户体验，地方和部门可以自行 决定多少次提交表单后再显示验证码。对于图形验证码的技术要求建议如下： 1） 验证码在设计上必须要考虑到相关安全因素，以免能被轻易地破解，常见的方式是增加背景干 扰元素； 2） 验证码在一次使用后要求立即失效，新的请求需要重新生成验证码，防止验证码多次有

17、效。 6.3.4 表单输入校验 地方和部门开发服务应用时必须对用户产生的输入内容进行校验，不能完全依赖于移动政务服务系 统前端校验，必须使用服务端代码对输入数据进行最终校验。前端校验只能作为辅助手段，减少前端和 服务端的信息交互次数。一旦发现数据不合法，应该告知用户输入非法并且建议用户纠正输入。一方面 DB36/T 11812019 7 是为了提升用户体验，另一方面是为了防止攻击者通过输入进行SQL注入、XSS攻击等恶意行为。 6.3.5 应用模拟测试 6.3.5.1 要求地方和部门联系移动政务服务系统支撑人员，申请开发者工具使用权限； 6.3.5.2 要求地方和部门应用审核前，对应用进行全面

18、测试，确保页面正常访问； 6.3.5.3 应用中所有涉及用户基本信息、证照信息、办事信息等系统已有数据，要求自动关联数据， 避免让用户二次输入。用户信息获取需按要求调用全省统一用户交互接口见附录A。 6.4 消息推送要求 为解决业务向用户实时精准推送各类信息、服务的需求，移动政务服务系统向接入的政务服务应用 提供了一套标准的业务消息接口，政务服务应用要求调用标准消息通知接口，以消息推送形式及时通知 到移动政务服务系统，在移动政务服务系统个人中心或消息模块等地方展示，让用户在最短时间触达消 息。地方和部门要求调用全省统一的消息通知推送接口进行消息推送见附录B。 6.5 业务埋点要求 为进行数据分

19、析，并作为地方和部门考核依据，要求应用开发时做好相应埋点设置，做好与运营数 据统计子系统的对接工作，保证数据真实可用。地方和部门要求调用全省统一的数据埋点接口见附录C 中表C.1、C.2、C.3，数据埋点方式包括新用户授权埋点、用户访问埋点、应用访问埋点。 6.6 安全保护要求 6.6.1 关键信息脱敏 个人敏感信息包括身份证号、手机号、固定电话号码、邮箱、家庭住址等，所有应用都必须妥善做 好敏感信息保护。对自动获取的敏感信息，进行信息脱敏处理，做好前端展现控制，不在用户端各交互 界面传递未脱敏的用户信息，防止因账号被盗用造成个人敏感信息泄露。信息脱敏要求参照全省统一的 脱敏规则见附录D。 6

20、.6.2 身份真实性控制 对于涉及用户隐私的，应仅限高级实名用户进入；如有必要，还可发起实时人脸识别身份验证。 6.6.3 用户授权确认 任何需调用用户个人隐私信息的服务，必须弹出个人信息使用授权提示，说明提取信息类型和用途， 经用户确认后方可使用。 6.6.4 支持HTTPS 为防止网络劫持、页面挂码等风险，要求移动政务服务系统支持HTTPS访问，接入单位在开发应用 服务时需保证页面加载的所有资源协议支持HTTPS访问。 7 移动政务服务应用审核要求 7.1 原则 测试人员根据测试审核要求对应用可用性、兼容性、安全性进行全方位审核，审核通过后方可发布 上架。 7.2 页面要求 为保证移动政务

21、服务应用在上架后用户体验一致，地方和部门需按照要求统一页面设计，增强用户 体验。具体页面要求如下： DB36/T 11812019 8 1） 兼容性高，能够适配不同手机机型； 2） 交互提示友好，不同使用场景下要有对应的使用引导； 3） 结构布局清晰，相同类型业务数据要归类展示，不同业务数据展示方式要有区分； 4） 体验流畅高效，页面数据展示延时最长不超过2s，页面切换平滑流畅； 5） 操作层级简化，完整流程页面跳转最多不超过5层，精简页面流程设计。 7.3 质量要求 7.3.1 服务风格统一。要求所有接入的应用保持文字大小统一、图片尺寸统一、按钮规格统一、表单 样式统一、加载效果统一、底部落

22、款统一。 7.3.2 服务功能完善。要求所有接入的应用在保障业务流程可行的前提下，事项办理流程简化，使用 正确控件，对接用户信息，避免二次登录，确保结果数据展示无误。 7.3.3 服务体验流畅。要求所有接入的应用考虑设备兼容苹果系统和安卓系统，避免出现空白页、错 链、死链等情况。 7.3.4 服务性能稳定。要求所有接入的应用接口响应快，能抗压抗并发，并准备故障解决预案。 7.3.5 服务安全可靠。要求所有接入的应用经过安全加密、数据脱敏等处理，并支持HTTPS安全协议。 8 移动政务服务应用管理要求 为保障移动政务服务系统不断接入更加优质的服务，参考国办发201845号文件调动社会资源力 量，

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

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

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

26、e, token: composeB7ee886d452524098b7c2d9c49a5bbX37, data: headpic: nickname: , email: 152*8584, cert_type: 0, name: 赖*, userid: 208811263318*, cardid: 362532*1714, mobile: 152*8584 DB36/T 11812019 10 B B 附 录 B （规范性附录） 动账消息推送示例及说明 B.1 动账消息推送接口 动账消息推送接口见表B.1。 表B.1 动账消息推送接口 服务名称 addMsgInfos (消息批量推送) 方法

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

28、 是 String 姓名 idcard 是 String 身份证号码 cityCode 是 String 城市编号（如南昌市：360100） opreateDate 是 String 操作日期（示例：2018-05-06） bdje 否 String 变动金额（示例：1999.9）（公积金业务推送填写） zzmc 否 String 证照名称（电子证照业务推送填写） 请求参数 params expireDate 否 String 过期时间（示例：2018-05-06）（电子证照业务推送填写） succ - String 返回码(true为成功，false为失败) msg - String 数据入

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

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

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

32、参数名 必选 类型范围 说明 name 是 String 姓名 idCard 是 String 身份证号码 isPopulariz e 是 String 是否来自推广活动（0否1是） popId 否 String 推广标识（isPopularize为1时填写） appName 是 String 应用名称 parId 是 String 应用所属栏目id appRemark 是 String 应用唯一标识 请求参数 parmas location 是 String 当前所在分厅名称（示例：赣州市） appType 是 String 应用类型（1普通应用2电子证照3服务专区） remark 是 St

33、ring 当前所在分厅行政区划编码（示例：360700） succ - Boolean 返回码(true为成功，false为失败) 返回结果 msg - String 结果消息 返回示例 msg:成功,succ:true DB36/T 11812019 13 C.3 新用户授权埋点接口 新用户授权埋点接口见表C.3。 表C.3 新用户授权埋点接口 服务名称 userAuthorize (新用户授权) 方法说明 该接口是实现对新用户授权进行埋点记录， 传入参数 params为对象json。 请求方法 POST URL地址 https:/API_ROOT/interface/buryPointUs

34、er/userAuthorize.do 参数名 必选 类型范围 说明 name 是 String 姓名 idCard 是 String 身份证号码 userid 是 String 支付宝用户标识 isPopulariz e 是 String 是否来自推广活动（0否1是） 请求参数 parmas popId 否 String 推广标识（isPopularize为1时填写） remark 是 String 当前所在分厅行政区划编码（示例：360700） succ - Boolean 返回码(true为成功，false为失败) 返回结果 msg - String 结果消息 返回示例 msg:成功,s

35、ucc:true DB36/T 11812019 14 D D 附 录 D （规范性附录） 敏感信息脱敏处理规则 D.1 敏感信息脱敏规则 敏感信息脱敏规则见表D.1。 表D.1 敏感信息脱敏规则 信息类型 处理规则 姓名 隐藏姓名中的第一个字，如为英文等其他语种，也是隐藏第一个字母。如：* 大友、*安、*ahn （单位名称无需做脱敏处理） 身份证号 1.强隐藏规则： 显示前1位和后1位，其它用*号代替。（凡是页面显示后无需用户检查确认的， 使用这个规则。） 示例：3*X 2.普通隐藏规则： 显示前1、5、6、7、8、9、10、11、12、18位，其余用*号代替。（凡是系统 显示后还需用户检查确认的，可使用这个规则。） 示例：3*23197402*X 军官证号、护照号等其他身份证件 显示前1/3和后1/3段字节，其他用*号代替 手机号 显示前3位+*+后4位。如：137*9050 固定电话号码 推荐的规范：显示区号和后4位，其余用*号代替，如：0571*8709 邮箱 前面的字符显示3位，3位后显示3个*，后面完整显示 如：con* 如果少于三位，则全部显示，前加*，例如 则显示为 tt* 银行卡卡号 显示前6位+ *（实际位数）+后4位。 如：622575*1496 其他各类敏感信息 显示前1/3和后1/3段字节，其他用*号代替。 _