2.5.3统一身份认证平台
信息化建设是一个动态的、发展的过程，随着各类信息系统不断增加完善，对信息安全、 权限管理、系统间交互的需求也将越来越强烈。原有各独立的应用服务系统各自为政的身份认 证方式已经难以适应发展的应用环境。学校需要有一个独立、安全、高效和可靠的身份认证及 权限管理系统，由此系统来完成对整个信息系统统一身份认证与权限管理。
身份认证系统将是数字校园建设的重要组成部分，该系统为数字校园的所有用户提供统一 的身份确认与权限交付。用户通过一次认证后，即可获得相应权限，并使用数字校园中所有应 用服务系统提供的服务。
另一方面，必须要有一个比较稳定的动态口令和统一身份认证系统很好地结合，这样每个 用户都具有一个静态口令和一个不断变化的动态口令，管理员可以设置用户静态口令和动态口 令不同的可使用范围，这样从另一个角度提高了整个信息化的安全性；这样的一个动态口令系 统必须能够和各应用系统的动态口令系统有很好的接口，使得在纵向可以做到动态口令的一致 性。
通过指定相应的集中认证技术规范，提供统一的应用系统用户管理接口，最终实现所有新 建系统用户认证的统一集中化管理，做到真正意义的集中认证。实现各应用系统的“集中认 证”，可以彻底改变各自为政、管理松散的用户管理模式，充分发挥学校内部网络管理维护部 门的管理职责，规范用户操作行为，强化用户合理使用网络资源的意识。本系统重点包括三个 方面：用户资料的集中存储和管理、用户身份集中的验证、访问权限的集中控制和管理。
2.5.3.1建设目标
随着应用建设的逐步深入，已经建成的和将要建成的各种数字校园应用系统存在不同的身 份认证方式，用户必须记忆不同的密码和身份。因此，要建设以目录服务和认证服务为基础的 统一用户管理、授权管理和身份认证体系，将组织信息、用户信息统一存储，进行分级授权 和集中身份认证，规范应用系统的用户认证方式。提高应用系统的安全性和用户使用的方便 性，实现全部应用的单点登录。即用户经统一应用门户登录后，从一个功能进入到另一个功能 时，系统平台依据用户的角与权限，完成对用户的一次性身份认证，提供该用户相应的活动 “场所”、信息资源和基于其权限的功能模块和工具。在学校工作人员进行了调动、调级、 调职等变更后，或者学校体制改革、组织机构变动后，使用户的身份和权限在各系统之 间协调同步，减少应用系统的开发和维护成本。
2.5.3.2建设内容及功能要求
统一身份认证平台应能实现身份数据的统一存储、统一管理，实现全校各类应用的单点登 陆，以及各类访问与操作安全审计。同时，还提供便利的工具，便于系统的维护和管理。平台 建设内容主要包括以下方面： ＞目录服务
目录服务是统一身份认证平台的基础。目录服务要以面向对象的数据库和LDAP的方式集中 管理用户信息，保证数据的一致性和完整性，为数字校园各类应用提供用户信息的共享。
LDAP(Lightweight Directory Access Protocol)是目录访问协议的一种，它基于 X.500 标准，但是简化了实现方法，所以称为轻量级的目录服务，相对于通常用于认证的关系数据库 而言，LDAP目录服务倾向于包含描述的基于属性的信息，并支持复杂的过滤器操作。它的数 据组织树型结构，在目录服务中称之为目录信息树(Directory Information Tree ,DIT),DIT的 基本组成单元是条目(Entry)，条目由多个属性构成，且可扩展 协议规定了 DN的命名方法、存 取控制方法、搜索格式、复制方法等，并提供了存取这些信息的服务。数据组织的树型结构可 以限定在目录信息树的任一分枝上进行目录查，这一特性使目录服务相对于专门的关系型数 据库的数据处理速度快一个数量级 的分布式目录服务通过分区(Partition)和复制 (Rep
lication) 功能将目录信息树上的数据分布到多个物理服务器上实现，为应用系统和服务 中的信息存储和管理提供了一个可扩展的结构支持广泛的应用编程语言，如C、Java、PHP、 Perl等都有自己的LDAP API，用户可以轻松选择适合自己的编程语言进行 相关应用的开发最新 的协议版本是V3，其后续的开发已经纳入全球互联网最具权威的技术标准化组织IETF。
目前，LDAP协议已经成为一个被广泛支持的用于统一身份认证跨平台和标准的协议，它的 易于集成不同应用系统的特点，成为支持网络系统的重要底层基础技术之一，是进行统一身份 认证的一个优选方案。
统一身份管理
统一身份管理要充分考虑学校业务中的需求，包含组织机构及用户管理、数据维护等功 能。提供职位变更的身份转换，组织机构的拆分和合并，支持组织机构的实体和虚体，支持 多级管理等，为SSO提供一个方便的身份管理平台。
✓组织机构及用户管理
✓要求支持管理创建多级组织机构、部门信息；
✓完成管理系统用户信息、机构管理员、机构负责人等配置；
✓投标方必须提供成熟的组织机构及用户管理模块，并提供相应的功能图片说明。
✓数据维护
✓要求提供数据维护工具来支持门户内组织机构、用户等数据的批量维护、导入、导 出等；
✓要求支持对导入的数据进行校验和审核；
✓要求提供相应的综合查询功能，能够完成批量用户密码初始化；
✓要求导入/导出工具提供给学校相应的模板，支持学校自主定制开发，并将免费提 供相应开发平台。
✓投标方必须提供成熟的数据维护管理模块，并提供相应的功能图片说明。
> 统一认证管理
统一认证系统主要是为其它系统提供认证服务，用户只需要登录一次，即通过一个应用 中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。
✓身份认证服务
✓php成绩管理系统要求基于LDAP和CAS认证方式设计，提供跨服务器及业务应用的身份认证服务及 Agent,确保跨业务系统身份认证识别；
✓支持多种认证方式：支持基于认证接口、认证代理和LDAP认证的多种认证集成模 式，支持用户/密码、CA证书认证、动态口令认证、智能卡认证等认证方式；
✓要求支持LDAPv3标准。
✓单点登录服务
✓要求提供WEB-SSO(Single Sign On)服务，用户只需要登录一次就可以访问所有 相互信任的WEB应用系统，投标方需详细描述单点登录机制。
✓个人自助服务
✓ 要求提供给所有用户修改密码、密码回、修改昵称等个人自助服务,给用户提供 更方便快捷的服务。
✓集服务
✓ 要求在内存中存储登录用户权限、角信息、组织机构信息登录信息,并通过集 广播向集内服务器发送,以实现认证服务器集扩展。
✓身份审核
✓对于组织机构的变动、角的变动以及权限变动要求提供身份审核功能；
✓在设计中，要考虑到大部分业务系统的身份管理都是用WEB和数据库方式，因此， 在这些系统中的用户认证方式应在身份认证服务器中完成；
✓对于支持LDAP认证的系统，并通过缓存技术和同步技术保证身份信息的唯一性和 一致性。
✓日志管理
✓要求详细记录对用户的信息的操作情况。
✓要求用户登录应用系统后对系统资源的所有访问都记入日志，以便事后对用户操作 进行审计，建立完善的事后追溯机制。
✓要求提供对所有的审核信息进行查询检索功能。
2.5.3.3技术要求
（1）平台基于J2EE体系结构，所有功能模块定义服务提供者接口（ Service Provider Interface），可以支持第三方的服务提供者；
（2）在身份认证系统设计中，为了适应当前以及今后系统的建设发展需要，建议采用的技 术实现手段主要包括LDAP、PKI、SSO、SSL等等；
（3）单点登录从实现技术上基于session、cookie、rewrite技术和采用portal等几种方法， 根据用户的情况可以选用其中的任何一种。
（4）平台的管理与维护采取分级模型支持多级的管理；
（5）采取分级授权，可以根据业务的需要灵活制定安全策略控制授权；
（6）采用灵活的基于角的权限管理模型，集中的权限控制的授权管理面向全局的用户和 数据资源，覆盖了各种应用；
（7）支持用户/密码、校园卡/密码和数字证书等认证方式；
（8）灵活定义角之间的继承、相容和互斥关系，授权简单、便捷；在访问控制策略上， 用户可以定制不同粗细粒度的安全规则；
2.5.3.4产品选型
现有的单点登录解决方案非常多，而且各个J2EE容器厂商都有各自专有的SSO产品。但是 J2EE标准未包含SSO方面的内容。尽管如此，大量的商业和开源团体都对SSO投入了巨大的资 源，并取得了非常好的成绩。CAS（Central Authentication Service，中央认证服务）是建立在开放 协议上的企业级SSO解决方案，它具有开源、安全、轻量、可扩展性强、容易部署的特点，并 在高校和企业中得到广泛的应用。
（1）CAS的组成与工作原理从体系结构上看，CAS包括CAS服务器端和CAS客户端代理 两部分。由于CAS2. 0协议借助于XML数据结构与客户进行交互，因此开发者可以使用各种
语言编写的CAS3客户与服务器进行通信，比如PHP、C++、Java（JSP）、Per等。CAS3服务器 采用Java开发而成，它要求目标运行环境实现Servlet 2.4规范提供J2SE 1.4的支持。
CAS Server负责完成对用户的认证工作，CAS Server需要独立部署，它是一个简单的WEB 应用，可以将其war文件直接部署的WEB容器中。CAS Server会处理用户名/密码等凭证 (Credentials),它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密 码，对这种方式，CAS提供统一灵活接口 /实现分离的方式。
CAS Client负责部署在客户端(指WEB应用)，CAS Client的部署意味着当有对本地WEB应 用的受保护资源的访问请求，需要对请求方进行身份认证，WEB应用不再接受任何的用户名密 码等类似的Credentials,而是重定向到CAS Server进行认证。
TGT(Tickect-Granting Ticket)是用于建立SSO登录用户身份的重要证据。一旦SSO用户成功 登录到CAS服务器后，CAS服务器便会生成一个TGT,并保存在CAS服务器中，CAS服务器 维护所有的TGT。通常，除了浏览器和CAS服务器外，客户端不会接触到TGT。
TGC(Ticket-Granting Cookie)是存储的TGT的Cookie。一旦登录到CAS服务器后，会在浏 览器中存储它。这是同CAS服务器交互的Cookie,只有HTTPS借助于传输通道，TGC才会被 传入到服务器。一旦浏览器关闭,便会被销毁掉。可以看的出一个会同时出现在服务器和浏览 器中，对于浏览器而言，TGT是以TGC的形式存在的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。