智慧校园建设方案！高校统一身份认证解决方案1.项目背景所谓身份认证，就是判断一个用户是否为合法用户的处理过程。
而统一身份认证是针对同一网络不同应用系统而言，采用统一的用户电子身份判断用户的合法性。
数字化校园网络中各个应用系统完成的服务功能各不相同，有些应用系统具有较高的独立性，如财务系统，有些应用系统需要协同合作完成某个特定任务，如教学系统、教务系统等。
由于这些应用系统彼此之间是松耦合的，各应用系统的建立没有遵循统一的数据标准，数据格式也各不相同，系统间无法实现有效的数据共享，于是便形成了网络环境下的信息孤岛。
对于需要使用多个不同应用系统的用户来说，如果各系统各自存储管理一份不同的身份认证方式，用户就需要记忆多个不同的密码和身份，并且用户在进入不同的应用系统时需要进行多次登录。
这不仅给用户也给系统管理带来了极大地不便。
随着现在信息技术的发展，校园网络提供的信息服务质量的提升，对信息安全性的要求也越来越高。
同时对用户的身份认证、权限管理的要求相应地提高。
原来各个应用系统各自为政的身份认证的方式难以达到这个要求。
这就必须要有一个统一的、高安全性和高可靠性的身份认证及权限管理系统。
该系统可以完成对整个校园网用户的身份和权限管理，保证各应用系统基于统一的模式、集中的环境开发与升级，一方面降低了系统整体运行的维护成本，另一方面保证了整个校园系统能够随着平台的升级而同步升级，方便使用和管理，也保证了整个系统的先进性与安全性。
有了统一身份认证系统，管理员就可以在整个网络内实现单点管理、用户可以实现一次登录、全网通行，各种管理应用系统可以通过统一的接口接入信息平台。
对用户的统一管理，一方面用在访问各个成员站点时无需多次注册登录，既给用户的使用带来方便，也为成员站点节约资源，避免各个成员站点分散管理统一用户带来的数据冗余。
另一方面也给新的成员站点(新的应用系统)的开发提供方便。
2.参数要点说明浏览器单次会话当中，通过一次登录就可以访问互相信任的系统。
✓支持多种认证协议，可以通过配置一键开启协议。
包括：CAS|Oauth|OpenID|LDAP|SAML|WS等。
完美兼容任意认证协议的第三方系统。
✓支持互联网平台认证接入，如：微信认证、微博认证。
✓支持多种语言类型的业务系统进行认证接入，包含但不限于Java，.Net，PHP，Ruby 等。
✓支持多种对称和非对称的加密算法，防止用户信息在传输过程中被窃取和篡改。
✓对后续的业务系统扩充和扩展具有良好的兼容性。
✓认证节点支持容器化、集群化部署，实现动态负载均衡。
✓用户认证记录全程日记记录。
3.系统特点●可插拔的认证方式（JAAS，LDAP，数据库，X.509等）；●支持多种协议（CAS，SAML，OAuth，OpenID，等）；●跨平台及多种客户端支持（Java，.Net，PHP，Perl，Apache，等）；●安全策略：使用票据（Ticket）来实现支持的认证协议；●支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；提供高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry等；4.主体功能4.1DashBoardDashBoard功能提供认证系统数据的可视化展现，主体包括：用户访问量、系统访问量、应用分布、应用排行等功能。
可视化概览支持用户自定议功能，可以按照用户偏好重新定义。
4.2统一用户中心卓云·超级身份认证不仅解决第三方系统登录授权的问题，还是整个学校的统一用户中心。
解决在校用户的数据唯一出口和唯一标准。
除了用于授权还可以对第三方系统提供用户信息共享服务，包括：用户类型管理、岗位信息管理、用户层次管理、用户登记管理、组织架构管理等功能。
统一用户中心的数据来源需要结合学校实际场景，制定数据交换规则，比如：用户数据来源于教务、一卡通等。
数据交换可以采用卓云的统一数据中心产品，也可以对接学校现有的数据交换产品。
统一用户中心原则上是整个学校统一的用户维护中心，也是唯一标准，保证重复使用的时候不会产生数据分支。
统一用户中心还负责管理临时用户，比如添加游客等。
统一用户中心还可以为其它业务系统提供用户数据共享4.3接入管理接入管理功能相当于第三方系统允许认证的授权中心，一方面提供接入系统的技术指导，另一方面对已经接入系统进行管理。
4.4安全管理对用户登录行为进行安全监控，包括：登录次数异常、登录频率异常、登录时间系统、侵入式登录等。
4.5统计分析统计分析功能目前主要体现为用户登录日志和系统登录日志两大块。
5.认证方式5.1数据库认证可以通过配置文件的方式来开启数据库级别的认证，CAS提供了各种组件来适应不同的数据库。
用户通过查询数据库中的用户名和密码来认证用户身份。
5.2LDAP认证LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。
它是基于X.500标准的，但是简单多了并且可以根据需要定制。
与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。
LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。
简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。
LDAP其实是一电话簿，类似于我们所使用诸如NIS(Network Information Service)、DNS(Domain Name Service)等网络目录，也类似于你在花园中所看到的树木。
不少LDAP 开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。
实际上，这种对比的基础是错误的。
LDAP和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。
LDAP 是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言SQL属同一级别。
LDAP最基本的形式是一个连接数据库的标准方式。
该数据库为读查询作了优化。
因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。
可以通过配置文件的方式来开启LDAP方式认证，CAS主要提供了两种LDAP的认证处理器：第一种，FastBindLdapAuthenticationHandler。
这种认证处理器一般用于DN是由用户名直接组成的，比如：uid=%u,ou=dev,dc=,dc=com,其中%u就是CAS登录的用户名。
第二种，BindLdapAuthenticationHandler。
这种认证处理器一般用于需要验证的用户名是DN的其他的属性比如email，而不是上面第一种处理器中的uid（当然uid属性同样适用，例如mail）。
CAS和LDAP，主要应用在系统整合情景中，CAS做多个系统的统一认证入口，只需要登录一次便访问多个系统。
而LDAP用来存储多个系统通用的信息，比如用户信息、用户权限信息，这些信息具有通用和简单（字符串为主）、更改性小的特点，又因为他们属于不同的组织，不同的系统，也就构成了树形的结构，形成了目录，这样的话，在匹配用户名和密码时，就可以做到高效的检索6.认证协议清单充分利用主流认证策略的优点，认证系统融合多种认证协议，第三方生产系统可以选择自己支持的认证协议进行身份接入，减少实施过程中的协调成本。
6.1支持认证协议–CASCAS（Central Authentication Service）是Yale大学发起的一个企业级的、开源的项目，旨在为Web应用系统提供一种可靠的单点登录解决方法（属于Web SSO）。
基础模式SSO访问流程主要有以下步骤：1.访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2.定向认证：SSO客户端会重定向用户请求到SSO服务器。
3.用户认证：用户身份认证。
4.发放票据：SSO服务器会产生一个随机的Service Ticket。
5.验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
6.传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
如上图：CAS Client与受保护的客户端应用部署在一起，以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS Client会分析HTTP请求中是否包含请求Service Ticket(ST上图中的Ticket)，如果没有，则说明该用户是没有经过认证的；于是CAS Client会重定向用户请求到CAS Server（Step2），并传递Service （要访问的目的资源地址）。
Step3是用户认证过程，如果用户提供了正确的Credentials，CAS Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，并且重定向用户到Service所在地址（附带刚才产生的Service Ticket）,并为客户端浏览器设置一个Ticket Granted Cookie（TGC）；CAS Client在拿到Service和新产生的Ticket过后，在Step5和Step6中与CAS Server进行身份核实，以确保Service Ticket 的合法性。
在该协议中，所有与CAS Server的交互均采用SSL协议，以确保ST和TGC的安全性。
协议工作过程中会有2次重定向的过程。
但是CAS Client与CAS Server之间进行Ticket验证的过程对于用户是透明的（使用HttpsURLConnection）。
CAS请求认证时序图如下：CAS的SSO实现方式可简化理解为：1个Cookie和N个Session。
CAS Server创建cookie，在所有应用认证时使用，各应用通过创建各自的Session来标识用户是否已登录。
用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在session里读取到用户信息，所以就不会去CAS Server认证。
如果在此浏览器里访问别的web应用时，客户端应用中的过滤器在session里读取不到用户信息，就会去CAS Server的login接口认证，但这时CAS Server会读取到浏览器传来的cookie（TGC），所以CAS Server不会要求用户去登录页面登录，只是会根据service参数生成一个Ticket，然后再和web应用做一个验证ticket的交互而已。
