智慧校园一期软件平台参数.docx

建设内容 序 号 1 设备名 技术要求和说明 称 应用管 理平台 一、总体目标 （包含 1) 基于 SOA 或微服务架构的松耦合方式，融合现代化管理理念和流 移动校 园平台） 程，建设能够全面支持学校整体运营管理和服务的数字校园基础平台。校 级数字校园基础平台提供统一管理数据、流程、用户、权限、服务的便捷、 安全、完善的手段，并为全校业务一站式服务系统的建设提供全面而有效 的技术手段。 2) 实现全校各类信息系统的基础数据和共享数据进行统一管理，并 提供灵活、多样的信息服务。 3) 校级数字校园基础平台具备集成和整合异构业务系统流程的能 力，通过统一的流程引擎将校内各业务流程进行统一的整合和运行，并能 对所有业务流程的运行情况进行统一的流程数据监控与分析。 4) 校级数字校园基础平台能够有效、合理地集成全校各种应用系统， 通过门户提供个性化的、方便的、高质量的信息化服务。 5) 校级数字校园基础平台能够统一管理基于该平台运行的所有功 能模块的运行状态：监视、统计、控制等。 6) 校级数字校园基础平台提供集成的二次开发环境和接口标准，能 够快速开发基于基础平台环境运行的各种应用与服务。 7) 建立有效的长期校内信息化运营保障机制。 二、技术路线 1) 本次智慧校园基础运行平台和应用系统均可运行于 Linux、 Unix、Windows 等高安全性操作系统。开发技术应采用 J2EE 标准、组件技 术及在数据交换上对 XML 的支持，使系统功能最优化，同时将整体系统内 部在技术上的相互依赖性减至最低。 2) 本次智慧校园基础运行平台和应用系统均要求采用 B/S 结构，采 用 Java 编程语言和服务器端 Java 技术进行开发，且必须基于 Oracle 11g 或以上版本。 3) 采用面向对象的组件技术，着重于开发构成应用程序“业务对象” 的可重复使用的组件，利用这些组件顺利地建立分布式应用程序。 4) 应用程序开发与运行结构要基于统一的技术开发平台的三层架 构，即 Web 服务器、应用支撑服务器和数据库服务器。 5) 能完成跨业务部门的业务流程和相对应的细颗粒度的分级授权 体系。 6) 各应用系统要充分利用现有先进技术手段，采用相同的体系结构 和运行平台，基于多层架构和组件技术进行构建，做到系统结构层次清晰。 所有应用逻辑、流程、数据等都应当能够根据建设方要求的颗粒度进行封 数量 装。 7) 系统必须支持负载均衡，支持动态监测负载状况，自动对可用资 源进行并发检测，调整和分配等功能。 8) 为保证系统运行的稳定性与安全性，本次智慧校园基础运行平台 如有涉及中间件产品，需采用主流的、成熟的商用中间件产品。 三、安全要求 1) 认证授权：保证用户的合法性和用户使用信息资源的权力，避免 内部敏感信息泄漏和服务所提供的信息资源被非法访问，造成严重的安全 事件。 2) 信息保密：充分利用密码技术，对于需要保密的信息，采用密码 技术进行加解密处理，防止信息的非授权泄漏，确保涉密信息在产生、存 储、传递和处理过程中的保密。 3) 数据完整性：建立数据完整性检验机制，保证收发双方数据的一 致性，防止信息被非授权修改。 4) 审计：记录应用日志，对事件进行分析，并能提供预警信息。 5) 数据备份：利用数据库的备份功能将建设的平台和系统数据备份 到指定的服务器或存储系统上。 6) 要求投标人从物理安全、网络安全、系统安全、应用软件安全、 用户安全、数据安全等几个方面提出配套的安全体系完善方案，以便防范 安全风险。 四、本期项目建设目标 智慧校园基础运行平台是保证校内各类应用运行与师生等各类用户进入 学校综合服务平台的唯一入口，建成后将为师生等各类用户提供一站式、 个性化的信息及应用服务。同时也为各类应用提供有效管理与对接的能力， 是构建学校数字化校园可持续发展生态体系的重要支撑工具。 本期项目建设要求 网上办事大厅 本次项目建设要求基础运行平台能够面向师生以网上办事大厅的形式直 观、便捷的校园信息化服务内容，办事大厅能够以 APP 形式、信息卡片形 式、集中式任务中心形式向用户提供服务内容和信息内容。 网上办事大厅必须充分考虑当前用户的使用场景和使用习惯，同时提供电 脑端入口和智能手机入口。 PC 端建设内容要求 首页 作为办事大厅的入口，提供登录功能，并支持在未登录的情况下按照各类 角色和办事类型预览办事大厅中的服务 个人桌面 用户登录后可直接显示个人办事桌面，个人桌面可以统一展现包括各类服 务、相关个人数据（如一卡通消费数据、个人邮箱数据、个人课表等）、 校内推荐业务、通知公告等。个人桌面还需支持以下功能： ★应用中心 我的收藏：用户可根据自行需要定义收藏的文件夹并在其中查询和 使用已收藏的应用。 可用应用：以侧边栏的形式将校内应用进行分类展示，用户可直接 在侧边栏中搜索相关应用并通过点击直接进入应用进行事务办理。 可用卡片：用户根据自身需要选择已有卡片是否在个人办事桌面中 显示。  任务消息中心 校内所有的信息推送、待办事项、事务流程和周期性服务都可以在任务消 息中心中进行统一展现和查询。 待办事项：所有的流程待办都可以在其中展现并通过点击直接处理， 无需再跳转到业务系统中。 流程追踪：对于和自己相关的流程进行状态查询，点击后可查询详 情。 周期服务：有业务期限至的服务可以在此查看到业务开放状态和截 止时间，点击后可直接办理。 未读消息：显示所有未读的系统消息，点击后可进入消息中心查询 历史消息。  自定义桌面 创建/修改主题桌面：用户根据自身需要创建不同的个人主题桌面， 并可对已创建的主题桌面进行修改或删除。 修改皮肤：用户可在线选择系统内置皮肤进行修改。 ★搜索中心 搜索中心是办事大厅中各类应用的聚集，用户可以在搜索中心中查询并获 取到所有与其相关的校内服务应用，搜索中心需要支持包括模糊搜索、标 签搜索、基于历史记录、最近访问等在内的搜索方式。 ★应用收藏 办事大厅中的每个应用均需要支持根据个人用户需要进行收藏功能，并在 收藏的同时根据对收藏夹进行管理。收藏后的应用直接进入应用中心-我 的收藏之中。 ★应用评价 办事大厅中的每个应用均需要支持评价功能，用户可根据自身使用感受在 线进行评价留言。 ★问题反馈 办事大厅需提供统一的问题反馈渠道，使用者可以在线进行问题的提报， 包括问题反馈内容、上传图片、预留联系方式。 ★内置卡片 办事大厅需预置部分信息展现卡片，保证办事大厅上线时个人桌面的展示 效果。如：推荐与最新应用、周期服务提醒、热门应用、专题推荐、个人 数据等。投标方需在标书中提供各类卡片的生产环境截图。 PC 端技术参数要求 1、开放性 遵循 Web Components 规范，可使用 Google Polymer 开发包。 2、可集成性 要求投标方所建系统按照统一的规范以服务的形式提供信息化基础能力 开放，让各种资源可以方便的集成到校园门户平台中，迅速的为用户提供 服务。对不同的业务需求可提供多种集成方式，可以为服务提供相应的平 台集成模板，保证良好的集成效果。 3、容错性 建设系统需要具备一定的容错性，在运行环境出现故障的时仍能提供稳定、 持续的服务。 投标方所建系统应支持并行运行多个节点实例，防止因为某个节点异常而 影响整个系统的运行效果。 4、高性能 投标方所建系统要能够在大规模用户的访问的情况下仍然能够提供高速 运行的服务，提供统一的分布式 key-value 内存数据库，实现对数据的缓 存，减少对磁盘读取的时间开销。 5、集群要求 平台需要具备集群工作模式，能实现多机热备和应用级负载均衡。 6、客户端环境要求 PC 端办事大厅需要考虑到用户浏览器的复杂性和多元化，需要支持的浏览 器包括 IE 9 及以上、MicrosoftEdge 13 及以上、Chrome 50 及以上、360 极速浏览器 v8.5 及以上、360 安全浏览器 v8.1 及以上。 移动端建设内容要求 鉴于师生在移动端的需求内容和使用方式的差异，要求投标方提供面向学 生和教职工两个群体不同的移动展现方式。面向学生的内容需要充分考虑 用户黏性和日活效果，面向教职工的内容需要充分考虑办事的便捷性与信 息获取的及时性。 面向学生  媒体内容 提供针能够向学生发布校内社交咨询及媒体内容的功能，包括混合信息流、 大学圈、校园号等功能。 混合信息流：支持按照栏目分类进行多形态的信息流推送功能，支 持图片、视频等多种形态。用户可对每条信息流进行点赞或评论。 大学圈：提供类似微信朋友圈的功能，教职工和学生均可在其中发 布信息，并能对其他人发布的信息进行评论、点赞、回复操作。 校园号：可将学校官方微信号的内容自动同步到校园号内，支持校 园号的创建、启停等管理操作。 所有的媒体内容及咨询均需要提供舆情控制功能，能够对敏感词进行过滤 与删除。 ★应用服务 移动端需要提供便捷的应用展示功能，能够按照 APP 分类查看服务，并支 持收藏功能。 移动端需提供以下内置应用，以保证用户日活： 今日课表 支持个人课表的多维度查看，包括按学期、周、日的课表切换，并可查询 每节课的详情。支持同步教务系统最新课表信息。 支持蹭课功能，用户可将课程库中的课程单个加入个人课表之中。 今日校园卡 对接校内一卡通系统，支持校园卡的余额查询、历史消费记录查询、校园 卡挂失、年度账单查询。  沟通协作 通讯录 用户可在校通讯录中查询联系人信息，包括学号/工号、学院、入学时间、 专业等。教职工信息可对学生屏蔽手机号码。可根据组织架构查询学校部 门负责人及电话。支持通讯录关注。 即时通讯 提供在线聊天功能，能够支持包括文字、图片、语音在内的聊天方式，支 持表情包下载，支持黑名单功能。同时需要和平台流程中心、任务中心结 合，推送相关消息。 面向教职工  日程咨询 结合校内业务系统，为教职工提供统一聚合的日程及咨询，将各个业务系 统的日常安排、通知公告都聚合在首页，便于教职工查询相关信息。  校园应用 移动端的校园应用中心，教职工获取应用服务的入口，支持应用的集中展 示和查询。 移动端技术参数要求 1、身份漫游 要求投标方所建系统能够对接招标方当前的身份认证平台。投标方应支持 移动门户和集成应用之间的身份无缝集成，移动平台为登录的唯一入口， 从平台进入应用无需用户输入用户密码再次登录。 2、灵活性 能够根据不同的使用对象（如普通教职工、学生、校领导）快速构建移动 门户界面，做到服务的可定制化。 3、抗网络波动性 由于移动设备具有网络不稳定的天生因素，投标方建设的系统应支持抗网 络波动性，如在离线情况下能做到离线缓存。 4、投标方建设的系统应为 H5 应用的开发提供原生能力调用接口，如相机、 相册、地理位置、文件系统、数据库、社会化分享，为开发功能丰富多样 的应用提供基石。 5、系统应具有完整的运营统计模型，便于招标方及时跟踪系统的运营状 况。 6、可集成性 投标方建设的系统应改拥有良好的集成策略，对不同的业务需求可提供多 种集成方式，保证良好的集成效果。 7、容错性 建设系统需要具备一定的容错性，在运行环境出现故障的时仍能提供稳定、 持续的服务。 投标方所建系统应支持并行运行多个节点实例，防止因为某个节点异常而 影响整个系统的运行效果。 8、高性能 投标方所建系统要能够在大规模用户的访问的情况下仍然能够提供高速 运行的服务。 9、集群要求 系统需要具备集群工作模式，能实现多机热备和应用级负载均衡。 10、安全性 系统的网络通道应通过 https 进行加固，防止网络传输过程中数据被篡改、 盗窃。 11、客户端运行环境要求 投标方提供单独的手机 APP 供用户使用，支持的手机操作系统需包括 Android 4.4 及以上、iOS 8.0 及以上。 五、应用管理中心 建设内容要求 应用管理 为办事大厅接入的各类应用提供统一的后台管理功能，具体功能要求如下： ★应用管理 可以在后台查询到其管理权限下的应用列表，并能够针对每个应用进行属 性配置，支持按业务域分配管理员，支持应用授权、支持应用开放时间与 维护时间的配置。  应用文件夹管理 管理员可在后台根据应用分类预设应用文件夹，并将类似应用放在同一个 文件夹之中，便于用户查找。  专题推荐管理 可以根据周期性业务设置专题推荐功能，包括对专题内容的编辑、开放与 关闭的管理功能。 系统管理 为办事大厅本身提供后台系统管理功能，便于管理人员设置办事大厅内容 和日常维护。具体功能要求如下：  桌面模板管理 支持管理员在后台设置办事大厅的主题桌面，并为主题桌面设置不同的卡 片及布局，同时支持对不同主题桌面的不同权限控制。  菜单管理 支持管理员对办事大厅的顶部菜单进行设置，通过该功能进一步拓展办事 大厅的使用场景与内容。 ★应用版本管理 对已有应用进行升级、部署等相应管理，包括批量下载应用包、应用包历 史版本下载、应用版本升级、部署地址管理功能。 ★平台版本管理 提供平台本身的版本管理，能够查询当前版本和历史更新记录。  缓存管理 提供对平台的缓存进行查询，能够查询到使用情况，并手动清理缓存。  个人提醒管理 提供对个人信息提醒进行统一管理，包括邮箱、一卡通等。同时需要内置 主流邮件系统的集成，无需二次开发。 业务域管理 支持管理员根据学校情况维护业务域，能够针对不同的业务域进行域管理 员配置，同时支持查询该域下面拥有的应用。 用户组管理 提供灵活的用户分组管理功能，管理员可以根据权限、业务等各方面需要， 灵活的新增、编辑、删除用户组。在用户组中支持动态与静态两种分配方 式。同时支持对用户组所拥有权限的应用及其状态进行预览。 ★意见反馈管理 对于在办事大厅中用户提交的意见反馈提供统一的查询与处理功能，相关 人员可以在本功能中对意见反馈进行回复。 ★评价管理 对于每个应用产生的评价数据，提供统一的查询功能，能够查询评价排名 前十、后十的应用，同时可以针对每个应用查看评价详情。 技术参数要求 1、遵循 SOA 架构 建设系统依据 SOA（Service Oriented Architecture） 的思想， 打破传统业务系统 （诸如教务系统、学工系统等等）的界限，真正以人为本，制定行业服务 粒度划分规范，以服务为核心，实现搭积木式的信息服务应用的开发方式， 通过基础服务的动态组合，随需应变，快速满足不同用户角色的信息服务 需求。 2、开放性 提供标准的应用构建、接入规范，可以兼容任何符合接入标准的业务应用， 并且提供丰富的应用程序编程接口或服务以供调用。遵循 Web Service 或 RESTful API 接口、Spring MVC Framework 标准架构。 3、可集成性 要求投标方所建系统按照统一的规范以服务的形式提供信息化基础能力 开放，让各种资源可以方便的集成到校园门户平台中，迅速的为用户提供 服务。对不同的业务需求可提供多种集成方式，可以为服务提供相应的平 台集成模板，保证良好的集成效果。 4、容错性 建设系统需要具备一定的容错性，在运行环境出现故障的时仍能提供稳定、 持续的服务。 投标方所建系统应支持并行运行多个节点实例，防止因为某个节点异常而 影响整个系统的运行效果。 5、高性能 投标方所建系统要能够在大规模用户的访问的情况下仍然能够提供高速 运行的服务，提供统一的分布式 key-value 内存数据库，实现对数据的缓 存，减少对磁盘读取的时间开销。 6、集群要求 平台需要具备集群工作模式，能实现多机热备和应用级负载均衡。 2 校园服 务总线 平台 建设内容要求 应用账号配置 提供管理员对应用账号进行配置的功能，可以根据不同的开发者配置不同 的账号，开发者后期根据此账号进行 API 的各类操作。 ★API 注册 提供接口供开发人员注册服务，仅需提供服务的相关元信息及 WSDL 文件， 即可实现注册步骤。而 WSDL 文件格式的基本验证部分需要自动完成，要 求服务提供者附加范例代码供第三方参考使用。其中的从属系统标签则用 于服务分组。对于 restful 形式的服务，需要提供详细的参数信息或提供 对于 restful 服务的输入和输出实例实现注册。 ★API 申请 提供接口供开发人员为所开发的应用申请服务的授权，申请以应用为单位。 开发人员在页面可看到所有服务的列表，仅需简单勾选可实现申请步骤。 ★API 监控 可以对各类 API 的使用情况进行监控，包括总体趋势（请求数量、服务总 数、错误数等）。能够监控的 API 必须包括已注册的 API 和代理 API。同 时能够对每个 API 的使用详情进行查询。 SMTP 配置 支持配置 SMTP 邮箱功能，API 的使用异常情况可以通过配置的邮箱及时通 知到相应人员。 技术参数要求 1、开放性 服务开放平台需支持以下协议： HTTP/S Web Service 2、通用性 支持基于 soap 协议的 Web service 接入， 从而实现使用开放的 XML 标准来 描述、发布、发现、协调和配置这些服务，方便开发分布式的互操作的 Web 应用。 对于利用主流框架 AXIS、CXF 等开发的服务，可以自动化解析与发布。 支持基于 http 协议的非 soap 服务集成。 支持基于 http 协议的 restful 服务接入集成，从而实现结构清晰、符合 标准、易于理解、扩展方便的 restful SOA 架构。 支持其他基于 http 协议的服务集成，如 json-rpc 协议。 3、可扩展性 服务统一管理与暴露，可以灵活的被第三方查询与调用。 提供服务接入规范，方便第三方接入，共享平台技术架构。 通过服务的集成，实现组件、模块的复用，从而实现易扩展的面向服务的 分布式体系架构。 支持集群、热备、负载均衡横向扩展。 4、安全性 提供消息级（Message-level）和传输级（Transport-level）的安全保证。 内部预设消息级的 accessToken 安全授权机制。 支持传输级的 https 通道。 API 查看、使用都要经过权限验证，并保障权限控制的安全性，有效性。 5、高性能 支持流量控制与服务的负载路由。 通过分布式总线集群的扩展，实现可承载的并发量的无限扩展；高并发 （1000 人）下服务总线通道可达到毫秒级的响应时间。 提供统一的分布式 key-value 内存数据库，实现对数据的缓存，减少对磁 盘读取的时间开销。 6、可管理性 界面友好，内部预设相关配置模板，简单填写相关参数即可完成服务的接 入。 集中的服务管理，不仅提供基本的服务治理，还能提供服务的 SLA 监控和 邮件告警机制。 提供服务器集群的历史运行数据，方便排查线上问题。 7、高可用性 当服务关闭后服务开放平台自动断连该服务的连接，防止少量的服务的故 障导致级联故障，进而造成了整个系统的不可用，这种现象被称为服务雪 崩效应。当服务启动后服务开放平台自动发现启动的服务，服务可以立即 正常使用。增加集群节点只需要安装对应的服务，不需要额外配置即可完 成系统扩展。 3 统一身 份认证 一、总体要求 （1）遵循统一规划、顶层设计的原则，从技术角度实现学校现有数据 资源、身份认证和访问界面的集成，搭建统一的应用集成框架，支持 未来应用的可持续发展，从“实现使用价值”的角度使得招标方的总 体收益最大化。 （2）引入 SOA 服务化、组件化的成功管理思想和技术，融合现代 化管理理念和流程，并根据高校的共性以及学校自身的特点，因地制 宜的打造一套满足学校整体运营管理和服务的业务身份统一与认证的 支持平台。通过信息化的手段强化学校身份账号的管理能力，提升面 向师生的身份账号服务水平，实现和谐发展。 （3）投标方提交的建设方案必须结合校方的具体需求，考虑到招 标方学校规模的可扩展性和长期可持续建设发展特性，要综合考虑当 下技术的发展趋势，确保系统建设切合招标方内部的工作、管理流程 和行业特性。本次平台建设过程中，要保证平台的可持续服务能力及 外部接入的开放能力。 二、安全性要求 （1）认证授权：保证用户的合法性和用户使用应用信息资源的权 力，避免内部敏感信息泄漏和服务所提供的信息资源被非法访问，造 成严重的安全事件。 （2）信息保密：充分利用密码技术，对于需要保密的信息，采用 密码技术进行加解密处理，防止信息的非授权泄漏，确保涉密信息在 产生、存储、传递和处理过程中的保密。 （3）数据完整性：建立数据完整性检验机制，保证收发双方数据 的一致性，防止信息被非授权修改。 （4）数据备份：利用数据库的备份功能将建设的平台和系统数据 备份到指定的服务器或存储系统上。 （5）要求投标方需从物理安全、网络安全、系统安全、应用软件 安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案， 以便防范安全风险。 三、建设内容 ●单点登录 1、身份认证服务 提供了平台的身份认证基础服务，实现 SSO 单点登录功能。包括 对用户身份的识别验证和对用户单点登录会话的管理和维护。支持用 户登录后在不同系统之间漫游而不需要再次输入密码。平台应支持 B/S 模 式 的 单 点 登 录 以 及 基 于 C/S 结 构 下 的 账 户 统 一 认 证 ， 包 括 ， Java、.Net、PHP 等。平台需能同时支持学校移动应用客户端的统一身 份认证集成，需能支持短信动态验证码的验证方式。为多帐号用户提 供账号绑定的功能，需提供密码变动短信通知功能。对安全级别要求 较高的系统，需提供特殊系统二次登录设置功能。 2、身份自助服务 包括个人资料编辑、密码修改、认证日志、个人设置、密码找回、 当前登录等功能。身份自助服务主要面向高校内的最终用户，包括所 有学生、教师和工作人员。身份自助服务可满足用户对自己帐号信息 和密码信息的维护需求，同时用户还可以查询到自己的帐号的使用信 息和维护信息。 3、反向代理服务 基于 nginx 的反向代理集成方式，集成接入方式简单，接入系统 可以直接从标准的 Header 中获取登录人员的相关信息，适用不同的开 发语言。 ●身份管理控制台 1、 系统概况 概况提供系统运行状态的总览，使管理员对当前系统的运行状态 一目了然，便于管理员及时发现问题和异常。管理员可以查看帐号概 况、认证概况、服务器状态和系统结构概况等。 2、 帐号管理 帐号功能帮助管理员完成全校身份帐号数据的查询、增加、删除、 修改、过期设置、锁定/解锁和加入组操作；需提供基于 Excel 文件的 帐号批量操作功能；提供基于差异视图的帐号同步功能；提供平台内 帐号操作行为的统计功能。 3、 认证管理 认证功能提供对全校身份认证相关数据的管理功能，包括对认证 集成应用的管理和全校用户认证行为记录的查询和统计。 4、 授权管理 提供校内身份类型组的管理功能，用于区分用户的身份类型，为 校内应用提供资源级授权。 同时应提供身份帐号入组和出组的管理功能，可基于 Excel 文件 实现批量操作；提供授权管理行为的统计功能。 5、 系统管理 需提供一些对平台运行起支撑作用的数据管理和功能设置，包括 操作日志管理、管理员管理和配置管理功能。 ●身份数据存储 按照学校特点和应用现状设计用户、组、权限模型，并按照模型 设计完成数据存储。所有的用户信息应分别存放在 LDAP 目录服务和数 据库中，通过可靠的机制完成两者的同步，用户身份信息在目录服务 中以层次结构，面向对象的数据库的方式集中存储管理，从而保证身 份数据的一致性和完整性，为校园各类应用提供一致的用户信息访问。 支持设置用户容器，方便平台和硬件平台、应用系统等通过 LDAP 接口的方式实现身份集成。 ●对外服务 1、 集成接口 为实现统一认证和单点登录提供接口和通道，可以支持跨平台和 各种开发语言的应用系统接入平台，如目前学校各类应用系统所使用 的 asp、.net、JAVA、PHP 等多种开发语言；支持 CAS4.0、SAML1.1、X509 协议，能将各类应用纳入认证范围，真正实现集中统一的认证。身份、 授权、认证功能相互独立，可以灵活的与第三方产品对接。支持底层 多种通用结构的认证技术协议，至少包括 LADP 等。 三、技术要求 1、标准化 ★·必须采用基于 LDAP 标准的目录服务器存储身份数据，并提供 身份认证。 ★·平台需基于 J2EE 标准架构，要求在安全认证方面基于 JAAS 技术。 2、可集成性 ★·提供多种认证接口的异构支持，包括代理认证和 LDAP 目录服 务接口。 ★·支持多种语言的接口方式， 包括 Nginx 反向代理、 Java、.Net、 PHP 等。 ★·支持 Unix、Linux、Windows 多种平台，完全支持跨平台的部 署。 3、可扩展性 ·身份、授权、认证功能相对独立。 ★·可实现用户名/口令认证模式，手机号绑定认证，支持动态口 令认证接口、CA 证书认证接口。 ·提供大并发访问下的高可用性，支持集群工作模式，具备多机 热备和负载均衡的能力。 ★·支持同一个域内的多个应用系统间的单点登录，具有开放的 跨平台 SSO 实现技术。支持学校移动 app 客户端的统一身份认证集成， 并能支持网页端、移动端同时登录。 4、安全性 要求系统对用户登录信息进行加密传输，保证数据能在客户端与 单点登录服务器之间、WEB 代理与单点登录服务器之间进行安全通信， 保证数据传输的安全性。 ·系统需提供用户密码加密功能，支持扩展 SSHA、MD5、SHA、RC4 等多种密码加密算法，加密算法不可逆，加密后数据不可被复制猜测； 并可以快速扩展用户属性信息。 ·基于非共享 Cookie 的 CAS 认证方式，集成应用不能读到 CAS 域 名下的安全令牌。 ·对用户的操作行为进行日志记录，以追溯用户的行为过失，确 保数据安全。 · 系统支持帐号恶意登录的锁定功能，并可通过短信提醒用户， 确保帐号安全。 ·系统支持帐号单点登录设置，确保同一时刻帐号只在一个终端 登录。 ★·需能支持二次登录的设置及异动提醒功能。 5、高性能 ·可为数百个应用提供统一身份认证服务的同时保证亚秒级的认 证操作时间。 ★·支持 10 万级的用户注册；常用服务器配置下，单机部署时应 能支持最大 800 人的并发用户数，双机负载均衡部署时支持 1500 人的 并发用户数。投标方需写明该负载情况的测试服务器配置。 对资源池连接数、滞后时间的调整（滞后时间是指在线用户多少 时间不活动，此用户的资源连接就应该释放）。 6、高效特性 ·提供灵活的同步策略配置，并通过小工具将权威数据源中新建 和变更的用户身份数据同步至统一身份认证与管理平台。 7、可管理性 集中的身份数据管理，不仅提供用户帐号的维护，还能提供便捷 的批量导入等功能。平台应提供相关服务器的软硬件环境的监视，发 现异常自动发出告警，并通知责任人。平台应提供历史事件的查询和 认证会话的相关操作，建立完善的事后追溯机制。 4 主数据 平台 一、总体技术要求 平台必须遵循 J2EE 的技术路线，采用 Java 编程语言和服务器端 Java 技术进行开发，主数据平台必须基于 oracle 10g 或以上版本的大 型数据库。 ★ 数据集成过程需采用成熟的商用中间件，能提供统一的可视化 的开发工具，能图形化的设计和定义抽取、转换、加载流程，并保证 数据集成交换的稳定性和安全性； 数据集成必须支持与主流关系型数据库进行对接，包括 Oracle、 IBM DB2 UDB、 IBM DB2/400、 Informix、 Microsoft SQL Server、 Sybase AS Enterprise、Sybase AS Anywhere； 数据集成必须支持与部分非主流关系型数据库进行对接，包括 Microsoft Access、Microsoft Excel、Dbase、Visual Foxpro； ★ 数据集成接口必须支持包括 JMS Topic 、JMS Queue 、Web Service、Tabled-Txt 文件、XML 文件、支持操作系统的网络协议，包 括 FTP； 支持包括 Unix、Linux 在内的多种平台，完全支持跨平台的部署。 二、信息标准建设要求 为配合和推进我校信息化建设，保证应用系统正常运行，需要建 立一个符合国家、教育部和行业标准的、适合我校信息化建设的规范 体系；要逐步建立和完善有关信息系统建设的各项规章制度和规范。 要让信息化建设落到实处，做到有章可循，有序建设，从而从制度上 保证整个系统的标准化、可扩展性、支持互操作、保证信息化工作的 顺利进行。以上建设目标都需要一套完善的信息标准管理工具来支撑。 投标方提供基于围绕校内信息标准建立后的信息化管理工具，便 于学校后期管理维护信息标准，同时能够对信息标准的执行情况进行 有效监控。 ★信息标准管理工具需要完全采用 B/S 架构，在不安装任何客户 端软件的基础上通过浏览器即可对校内信息标准进行管理，便于用户 维护使用。 信息标准管理工具主要建设内容包括以下三个方面： 代码标准模式及数据 1、初始标准预设 投标方需提供一套初始信息标准，包括代码标准、数据模式标准 和字段属性。提供的初始标准需符合教育部最新发布的教育信息化标 准。 2、核心校标制定 在初始标准的基础上，投标方配合校方完成核心校内执行标准的 制定，主要核心校标应包括：学校校区、学校组织机构、教职工人员 分类及一卡通号/职工号编号规范、本科生一卡通号/学号编号规范、 研究生一卡通号/学号编号规范。 ●代码标准管理工具 能够实现代码标准的新增、启用、拆分、合并、停用、导入、导 出功能，便于用户对代码标准进行日常维护； 能够提供包括对代码标准、代码标准模式、代码映射关系、代码 使用范围在内的代码标准查询功能，支持代码表、代码内容的模糊检 索； ★能够实现代码标准的分级授权管理，根据角色提供不同的代码 标准管理查询功能。 ●管理与配置 可对系统角色、用户进行管理；对系统的访问日志、模块访问日 志、模块操作日志、元数据变更日志、代码标准变更日志、系统异常 日志、调度任务运行日志提供查询、导出、删除功能。 三、数据集成与共享建设要求 数据集成与共享平台的建设是本次主数据平台建设的重点内容， 投标方需要采用统一的数据集成管理工具，将分散在各业务系统之中 需共享的主数据抽取上来，并根据校内信息标准进行统一的存储和对 外发布及共享，数据集成过程需采用成熟的商用中间件实现，以保证 数据交换过程的稳定与安全。并能够为校方提供对应的管理与配置工 具，提升数据集成过程的管理能力。 数据集成与共享具体建设要求如下： 数据集成工具 1、主数据模式及主数据库 主数据库的数据规范需要基于教育部最新的教育信息化数据标准， 并对其存储的数据对象按合理的数据模型进行划分。 2、数据集成开发包 能够通过 ETL 的方式能够将各异构业务系统的主数据抽取上来， 形成校内统一的、权威的主数据集； 提供包括拓扑管理工具、集成设计工具、集成查看工具、集成调 度工具在内的数据集成管理工具，工具需要具备可视化、可拖拽、可 配置的特性，并具备一定的二次开发功能，便于各个层面的管理人员 进行使用； ★提供数据集成知识库，知识库需要预置超过 100 个数据集成知 识模块。 3、元数据管理工具 能够对数据源进行注册、启用、停用； 能够对数据对象按目录结构进行管理，能够实现对数据对象和其 分类目录的增删改查； ★能够对元数据的变更进行操作记录历史查询； 能够根据元数据对主数据库进行建模并且保证建模过程不会操作 业务系统数据结构； ★能够对主数据库数据对象和对应的数据库实体匹配情况进行自 动检查，并逐项列出不一致项，方便用户后期处理，同时支持对已处 理问题进行记录，便于后期查询跟踪。 4、主数据管理 考虑到学校部分业务部门尚未建立信息系统，其他业务系统又需 要使用其业务数据的情况，投标方需提供手工将本地数据（包括 EXCEL、DBF）导入主数据平台之中，供其他业务系统使用的功能； ★ 通过主数据管理工具， 可以查询主数据和主数据历史变化情况， 并能够导出 EXCEL，便于线下开展数据分析； ★ 能实现主数据的分级授权管理，可根据数据流向控制其管理查 询权限。 5、数据集成核心模块 包括拓扑管理、集成设计、集成查看、集成调度等核心功能。 四、数据存储建设要求 数据的存储方式是整个主数据平台建设的基础，系统除了要考虑 主数据本身的存储之外，还需要考虑到后期为数据分析、数据积累提 供良好的支撑。同时数据库存储的设计要具备良好的合理性和科学性。 ★数据备份管理 ★ 提供数据备份管理功能，可对备份日志进行查询，可对主数据 变动情况进行查询，并能够将变动情况导出 excel。 ★能够在系统内随时查询某个历史时间点的主数据状况和代码标 准情况，时间点的颗粒度要细化到以天为单位。 数据的份需要采取合理的备份模式，要既能完整保留历史数据的 变动信息，同时不能过度浪费存储空间。