《XX大学身份治理平台项目采购需求》由会员分享，可在线阅读，更多相关《XX大学身份治理平台项目采购需求（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协议对所有数据传输进行加密；要求系统能够对用户登录信息进行加密传输，保证数据能在客户端与单点登录服务器之间进行安全通信，保证数据传输的安全性。2.6.1.2 帐号行为跟踪对用户的操作行为进行日志记录，以追溯用户的行为，确保数据安全。2.6.13日志管理日志系统需支持针对APl的调用日志进行查询，要求可以查看到APl调用来源IP、调用信息、事件内容及调用时间等信息。日志系统需对所有认证服务保留日志。所有
