《XX大学身份治理平台项目采购需求.docx》由会员分享，可在线阅读，更多相关《XX大学身份治理平台项目采购需求.docx（14页珍藏版）》请在三一办公上搜索。
1、XX大学身份治理平台项目采购需求1 .相关标准、行业标准、地方标准或者其他标准、规范如技术要求中未注明需执行的国家相关标准、行业标准、地方标准或者其他标准、规范的，执行最新标准、规范。2 ,需实现的功能或者目标2.1 项目背景随着我校信息化的不断深入,信息化环境越来越复杂，众多业务系统的建设，一方面为学校带来了先进高效的管理方法和工作平台，帮助师生更好的完成业务,另一方面也为师生的日常工作、校园业务系统的管理和安全带来了更多的问题和风险，例如身份定义不清、身份与控制无关、身份管理不完整、人工授权而不是自动授权等等。因而需要建设完整、权威、开放的身份管理体系，作为我校信息化生态圈所必备的基础设施
2、。基于开放的标准体系，为学校信息化建设提供一个完整、统一、先进、可扩展的身份治理平台，该平台符合互联网开放标准，能够安全、高效地实现各类校内外应用的接入，服务于各类用户，成为一个权威的、面向所有师生的身份体系，并由学校各类相关人员进行管理。同时系统的性能和可扩展性应能符合全体用户的使用需要，用户包括教职工、学生、应用开发者以及其他相关人员。2.2 项目目标该整体设计必须以问题为导向，以全量精确为目标，以数据安全为底限，以集约易用为原则，对人员进行全生命周期管理，对数据行为进行全过程管控，提升线上线下协同的精准人员治理能力，未来形成学校唯一、权威、及时、有效的全量人员基本信息中心，并共享给校内各
3、业务系统使用，分级分类开放给不同场景应用，营造完善的人员信息智能应用生态。另一方面需要建设统一的身份治理体系，实现身份数据的一体化管理与全生命周期治理，实现集中的身份管理目标。2.3 项目总体要求2.3.1 一人多身份要求本次身份平台需要满足学校实际业务一人多身份场景的需要，即一个人在学校多身份同时生效的场景下，无需进行身份绑定、身份切换，有身份平台提供身份数据时，直接给出所有身份信息供接入身份平台的系统使用。2.3.2 登录信息和身份信息分离要求为了方便用户进行身份验证以及登录后系统的使用，需要对登录帐号信息和身份信息进行分离，即登录帐号信息可以是用户自定义的用户名、也可以是学工号、甚至是邮
4、箱等信息，这些信息仅用于登录的验证，和登录后的用户身份信息没有必然关联。2. 3.3身份定义标准要求1、给出人员ID和身份ID的关系，并以人为主要身份标识；2、规范未来系统建设模式；3、彻底根治一人多身份的问题，多身份用户看到其相关身份的应用；4、给出其他系统使用身份的规范，可输出人员、组织、岗位、身份等数据；5、明确身份信息和登录信息无关，可使用用户名、学工号、身份等属性；6、参数可传递人员信息和身份列表；7、单一身份用户登陆经过判断即可进入，多身份用户可以选择或可以切换不同身份。2.3.4形成X大特征的多组织机构体系1、可按照学校要求，可对学校现有得职能部门、党务组织、学术组织、领导小组、
5、工会组织、校友组织等组织机构进行分类；2、系统设有统一的数据维护、统一的系统管理，可统一查看组织机构。2.3.5形成X大特征的岗位体系要求1、提供完整的岗位定义、分类和管理，对学校现有职务岗位、学术岗位、管理岗位、党务岗位、业务岗位、人员类别岗位等不同岗位进行分类。2、实现统一的岗位管理模式1）流程治理：对于组织机构的新增、变更、撤销增加流程管理能力，需要发起、审批、确认，然后自动创建2）业务数据治理：提供学术委员会管理功能，可以提供新增、编辑、成员管理、换届等业务数据管理功能，让对应的岗位人员自行管理。2. 3.6实现身份信息全生命周期管理实现身份元素的全生命周期管理，从进入到变更、到终止以
6、及撤销的全过程管理：1、定义人员身份信息、组织机构和岗位的对应关系；2、一人多身份的建立，可展现同一时间在不同组织机构担任不同的岗位职责，也可展现同一时间存在多种人员类别信息；3、定义身份有效期；4、实现可视化治理过程和模式，从后台服务变成了前台可视化；5、规范身份管理模式，从原来的手工处理、线下处理变成线上和规范管理；6、形成身份的统一展现。3. 3.7实现多种身份治理模式1、权威源治理已有业务为/数据中心，可以作为权威源接入，也可以构建权威源，建立相关的管理模块，例如在编教职工、本科生。2、流程治理使用流程能力进行治理，实现身份相关内容的规范化管理过程，例如聘用人员注册、访客预约流程。3、
7、分级授权治理对于没有前两者的方式，可以提供分级的权限管理，下放权力，例如院系办公室主任、办公室秘书。4、管理治理使用管理员权限进行管理，用于当前没有明确的场景，例如特殊人才、厂商测试人员。2.4功能要求2.4.1 身份管理2.4.1.1 组织机构管理提供学校的多种组织机构的管理功能，包含添加、编辑、删除和查询，并可以设置上下级关系，形成学校的组织机构管理体系。提供组织机构信息的导入导出功能。能够按照树形结构进行组织机构展示。支持查看组织机构变更历程。需要能够通过拖拽的方式对组织机构进行排序。2.4.1.2 岗位管理提供学校多种岗位的管理功能，包含岗位的新增、编辑、删除以及查询，并可以设置岗位的
8、层级关系。提供岗位信息的导入导出功能。岗位体系需要体现教职工、学生岗位。2.4.1.3 人员管理提供对人的管理功能，包含新增、编辑、删除以及查询。提供人员信息的导入导出功能。2.4.1.4 身份管理提供人员身份的管理功能，包含身份的新增、编辑、删除以及查询。2.4.1.5 扩展属性管理可以针对组织机构、岗位、人员属性进行扩展，以便满足灵活扩展的需要。2.4.1.6 人员手工合重可以通过人工方式，对两个人员信息进行手工合重，使得可能来自不同原来的人员信息进行合并，避免出现一人多帐号的情况。2.4.1.7 组织机构类型管理可以对组织机构类型进行定义和管理，以便区分不同类型的组织机构树。2.4.1.
9、8 岗位类型管理可以对岗位类型进行定义和管理，以便区分不同的岗位类型。2.4.1.9 单位类型管理可以对单位类型进行定义和管理，以便区分不同的单位类型。2.4.1.10 组织信息的可视化展现需要提供组织机构的可视化展现，一方面能够展示多棵组织机构树，另一方面可以通过多层级展示组织机构体系，灵活展开下一级，也可以收起，最后也能直接查看对应组织下的人员列表，以及身份信息。2.4.1.11 重点监控(1)支持空岗监控，如某个部门下漏配业务岗位下的人员，系统可以进行直观展示，支持主动给管理人员发送提醒信息。(2)支持孤儿监控，如删除某个部门后依然存在这个部门下的子部门。2.4.2 身份治理2.4.2.
10、1 组织机构治理提供针对组织机构的治理，包含是否开启治理、添加规则、保存、预览等功能，实现组织机构的合并等处理策略。2.4.2.2 岗位治理提供针对岗位的治理，包含是否开启治理、添加规则、保存、预览等功能，实现岗位的合并等处理策略。2.4.23人员身份治理提供针对人员身份的治理，包含新增、编辑、删除等功能，实现人员身份信息进入身份平台的处理策略。提供详情展示功能，可以查看对应人员身份治理规则配置的结果内容，可以添加治理规则，治理规则需要包括：挂载规则、数据映射规则、排除规则和同步方式。提供预览功能，可以查看预期结果。2.4.2.4 权威源管理能够配置各种权威源，作为身份信息的来源，并可以配置策
11、略，以便身份数据按照设定的规则进行治理。（1）权威源提供新增、编辑、删除功能。（2）权威源可以在不同的数据类型，包含人员、组织机构、岗位和人员身份类型上，添加、编辑、删除对应的规则。（3）具体规则的配置，可以是系统推送数据，也可以主动获取数据。（4）在主动获取数据的模式中，可以选择数据源，并进行字段映射。（5）在规则配置中，可以配置自动合重规则，对相同数据进行自动化合重。2.4.2.5 治理运行监控可以查看治理自动化运行任务的执行情况。（1）提供手动同步功能，实现数据立刻同步。（2）提供日志下载，便于排查问题。（3）可以配置监控规则，以便拦截批量数据异常导致的系统问题。（4）可以查询某个时间段
12、的任务运行情况，内容包含同步次数、同步状态，便于了解数据变化及问题的排查。2. 4.3权限及预警管理3. 4.3.1权限及提醒管理系统交付后，需明确职责，分配权限，各个部门可使用自己部门相关模块;系统须对接消息提醒平台，建立相应提醒机制，可对管理员设置、岗位变动等操作进行提醒；2. 4.3.2岗位预警1、不相容岗位预警；2、高危岗位人员冲突预警；2.5非功能性要求2.5.1 开放能力2.5.1.1身份信息开放API身份信息开放API,提供了一组可以让第三方系统调用身份信息的服务，以便让第三方系统可以按需获取身份治理平台提供的身份信息，接口提供动态接口支持，即传递不同参数，返回不同的内容。身份信
13、息APl的接口，包含（1）组织机构信息；（2）岗位信息；（3）人员信息；（4）身份信息；（5）身份信息APl的调用需要授权才能访问，授权需要支持OAUth协议。2.5.2身份治理平台建设服务2.5.2.1平台实施服务项目实施期间，提供不少于1人的驻场实施服务，根据学校具体要求，制定相关实施步骤及策略，明确人员信息模型，完成初始化和调整初始配置，并根据实际情况调整身份治理平台的对应治理策略。2.5.2.2组织机构梳理服务针对学校组织机构信息进行梳理，形成完整的组织机构管理和治理过程。具体组织机构内容需要包含：（1）单位类型组织机构;(2)党务类型组织机构；(3)学术组织机构；(4)领导小组组织机
14、构；(5)工会组织机构。2.5.2.3岗位梳理服务针对学校岗位信息进行梳理，形成完整的岗位管理和治理过程。具体岗位内容需要包含：(1)人员类别岗：需要包含在编教职工、聘用人员、本科生、硕士研究生、博士研究生、访客等人员类别。(2)职务岗：需要包含行政职务(校长、书记、部门正职、部门副职)、党务职务(党组织书记、党组织副书记)、辅导员等职务。(3)管理岗：需要包系统管理员岗、部门IT管理员岗等管理岗。(4)业务岗：需要涵盖当前校内运行的一网通办的业务岗等业务岗。2.5.2.4人员梳理服务针对学校人员信息进行梳理，形成完整的人员管理和治理过程。具体人员内容需要包含：(1)多源头人员：包含教职工人员
15、、本科生人员、研究生人员、聘用人员以及访客人员。(2)人员合重：对对源头人员进行合重梳理。2.5.2.5身份梳理服务针对以上组织机构、岗位、人员形成的人员身份信息进行梳理，提供完整的身份管理和治理过程。具体实施步骤；明确人员信息模型；初始化和调整初始配置；已有数据治理；数据同步的机制；数据库方式；API方式；身份治理策略调整；启用治理暂停身份治理同步；删除对应的治理策略；调整对应治理策略；增加对应的治理策略；关闭治理策略；查看治理任务执行情况。2.6 安全与性能要求2.6.1 安全要求2.6.1.1 数据安全传输支持采用HTTPS协议对所有数据传输进行加密；要求系统能够对用户登录信息进行加密传
16、输，保证数据能在客户端与单点登录服务器之间进行安全通信，保证数据传输的安全性。2.6.1.2 帐号行为跟踪对用户的操作行为进行日志记录，以追溯用户的行为，确保数据安全。2.6.13日志管理日志系统需支持针对APl的调用日志进行查询，要求可以查看到APl调用来源IP、调用信息、事件内容及调用时间等信息。日志系统需对所有认证服务保留日志。所有日志至少保留6个月以上。2.6.2 性能要求2.6.2.1 高可用性要求采用高可靠的技术架构，支持基于软件和硬件负载均衡设备的多机部署。保证系统的高稳定性;需要支持弹性扩展能力，通过配置允许在并发压力大的情况下，自动侵占资源以便保证认证系统的稳定。2.6.2.
17、2 可扩展性要求支持系统多机/多服务部署和横向无限制扩展。须具有扩展灵活，响应灵敏度高,操作方便等特点，可以根据实际应用过程中的需求变化,进行快速的调整，维护周期短，升级成本低。2.7 技术架构及标准化要求2.7.1 支持云原生方式部署运行身份平台需要能够按照云原生的HelmCharts方式进行部署，并能够运行在云原生环境中。一方面便于后续的升级维护，提升部署效率，另一方面屏蔽对底层操作系统的依赖，提升兼容能力。支持多实例运行，例如默认1个实例可以变成2个实例。变成O个实例时，系统无法访问。2.7.2 采用BZS架构需要采用B/S架构，须能运行于多种浏览器，包含IElO以上、GOOgleChr
18、ome、360浏览器、火狐浏览器等主流Webkit内核浏览器。2.7.3 Java开发语言需要使用JaVa语言开发，以便符合学校总体的技术架构和运维体系。2.7.4 支持OAUTH2.0协议支持0uth2.0协议，可为桌面程序和基于B/S的web应用提供授权API服务。第三方应用可使用学校账号认证登录，同时，学校用户也可使用微信等社交账号认证登录学校应用。2.7.5 提供开放接口支持用户身份信息等通过标准的Restful接口进行安全的调用，同时调用需要使用OAUth2.0协议进行安全访问。2. 7.6标准文档输出身份治理后，需输出相关标准文档，供后续项目对接使用。2.8 项目实施要求2.8.1
19、 项目实施计划要求项目实施时制定项目实施计划，要求合同签订之日起60天内完成项目所要求的建设内容的建设工作,并上线试运行,试运行结束后，中标方可以申请项目验收工作，在分阶段实施计划的基础上，进一步明确和细化每个阶段的工作范围、内容、人力投入、过程、责任、交付成果等。2.8.2 项目实施服务要求项目负责人需具备较强的技术能力及良好的沟通协调能力，至少担任过3个类似项目负责人的经验，需提供相关证明材料；项目实施期间,中标人需提供不少于1人的技术工程师负责本项目驻场实施工作,直至项目验收完成。2.8.3 验收方法及标准要求(1)本项目采用现场运行、测试验收方式验收。中标人完成的开发项目达到的质量标准
20、需符合国家、地方及相关政府管理部门和行业与本项目有关的各项技术标准、规范要求，并满足采购人实际需求，前述标准、规范等不一致的，以要求高(严格)的为准。(2)本项目连续2次验收未获通过，采购人有权解除合同并按照合同约定的违约条款处理。2.8.4 验收及付款方式(1)中标人在开发的各里程碑过程中须按照软件开发规范提供相关的成果，包括并不限于：软件需求说明书(经校方认可的)、软件设计说明书(概要和详细)、数据库说明书、接口文档、软件测试报告、试运行报告、使用手册、安装部署手册、成果光盘等资料及过程成果。本次独立开发的软件业务成果所有权归双方共有。(2)项目竣工时，除提交第1条所述相关文档、成果外，还
21、须提供完整的的平台安装、部署、测试环境、应用环境等相关文档；所有提供的源代码、数据字典、代码表等原始资料须是注释清晰的、可读、可利用、可供二次开发的。当软件发生升级、调整时，须提供更新的版本。2.8.5 成果和知识产权中标人需确保其完成本合同要求所利用、提交的所有数据、文件、资料及为完成项目而实施的其它工作没有侵犯任何人的专利权、商标权及其他知识产权。中标人保证采购人均不会因其履行合同义务而引起的在专利权、商标权以及其他知识产权方面,发生针对采购人的任何第三方的索赔。如有发生，中标人将负责处理并承担由此引起的法律责任以及包括律师费用在内的一切费用及损害赔偿。在本期项目的开发过程中和交付使用后，
22、要求将各个阶段产生的全面、规范的成果和文档资料交付给学校，而且需要提供明确的交付清单。同时，成果和文档资料需符合软件工程的相关要求。要交付的成果和文档资料需要包括以下部分：(1)可运行的系统。(2)技术文档：包括项目开发中的各种技术文档，如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等。(3)管理文档：包括项目开发中的一些工作文档，如，计划、报告、讨论纲要、会议记录等。2.8.6 培训服务要求通过培训会、实际操作和实际工作的参与，使得学校的管理员可以熟悉掌握并独立开发维护流程，具体培训内
23、容如下：(1)产品的使用方法及涉及的相关知识培训；(2)流程开发培训：通过开发培训，使得学校人员对流程开发整个过程有个清晰的认识，可以独立开发简单的流程，并可以进行测试、发布、管理。(3)系统运维培训：通过系统运维培训，可以对系统的部署架构有一定的了解，能掌握系统部署安装的整个过程，并可以处理系统遇到的简单故隙，使学校人员具有简单故障处理能力。(4)平台管理培训：通过平台管理培训，使得学校人员了解熟悉平台，能监控平台运行的整体情况，对流程可以进行干预，掌握如何分析流程执行效率。2.9 售后服务要求(1)本次采购项目自验收合格后，软件产品提供2年质保期，质保期内升级及维保，质保期自验收合格之日起
24、计算，中标人应提供因平台系统及其他设备本身缺陷所导致故障的技术服务和维修。中标人应按照本采购项目特点提供长期良好的售后服务,并在响应文件中提供详细具体的售后服务承诺条款及保证。(2)中标人应向采购人提供完善周到的技术服务，提供售后服务质量保障方案，建立完善的售后服务管理体系及拥有专业的维护队伍，保证系统的正常运行措施，质保期内质量保证提供技术支持、保修、系统升级和维护，不得另行收取其他费用，且保修服务方式均为中标人上门保修，即由中标人到采购人使用现场维修，产生的一切费用均由中标人承担。(3)中标人需提供7X24小时服务。对于系统在使用过程中出现的问题，在1小时内响应。如遇与所供系统有关的问题无
25、法远程解决的，一般性故障解决问题时间不超过4小时，重大故障4小时内给出解决方案并提供临时应急处置措施，重大故障解决问题时间不超过72小时。因中标人工作延误，造成采购人损失的，中标人应负赔偿责任，具体赔偿方案在签订合同时订立。在服务期内，中标人对平台出现的技术问题负责处理解决并承担一切费用。(4)质保期内须提供并不限于以下服务:服务项服务内容服务项说明基本支持服务电话服务7X24小时电话支持指导服务。远程服务5X8远程支持指导服务。上门服务如情况紧急，需提供上门服务，响应时间不超过4个小时。系统健康检查服务系统健康检查服务按照季度为频率，对系统进行健康检查。检查完毕，在两到三个工作日之内出具健康
26、检查报告以及对相关问题进行处理。应及时升级系统服务器操作系统漏洞补丁，及时升级防病毒等安全软件病毒库等。运维保障服务系统升级规划与实施服务协助用户对系统升级进行规划以及实施，并出具相应的升级规划报告以及升级注意事项。升级成功后，出具相应的升级过程报告。系统数据备份与恢复方案设计、实施和评估协助用户对数据文件备份策略进行合理的规划，以及实施备份与评估相应的备份策略。系统安全检查与设置协助用户设计系统的安全使用规范以及对系统账户进行安全审计与检查。现场问题的诊断与分析对与现场环境有密切关系的系统问题予以诊断并解决问题，最终将深入分析问题的原因，如BUG等。基础优化配置和性能调整对系统进行基本的优化配置以及性能调整，包括微调的个性化改动和升级服务。软件BUG的修复提供保证系统正常运行的BUG修复。补丁包升级服务期内采购人享有对所购买产品升级/打补丁的权力，中标人根据用户的申请提供当前支持的具有新增功能的升级软件产品、以及软件修复包。紧急故障处理对于突发性系统遇到的一些非物理结构损坏的故障而引起业务的中断，中标人应对该故障进行紧急处理。
