智慧校园建设方案!高校统一身份认证解决方案

智慧校园建设方案！高校统一身份认证解决方案

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.1DashBoard

DashBoard功能提供认证系统数据的可视化展现，主体包括：用户访问量、系统访问量、应用分布、应用排行等功能。可视化概览支持用户自定议功能，可以按照用户偏好重新定义。

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=https://www.360docs.net/doc/67970374.html,,dc=com,其中%u就是CAS登录的用户名。

第二种，BindLdapAuthenticationHandler。

这种认证处理器一般用于需要验证的用户名是DN的其他的属性比如email，而不是上面第一种处理器中的uid（当然uid属性同样适用，例如mail）。

CAS和LDAP，主要应用在系统整合情景中，CAS做多个系统的统一认证入口，只需要登录一次便访问多个系统。而LDAP用来存储多个系统通用的信息，比如用户信息、用户权限信息，这些信息具有通用和简单（字符串为主）、更改性小的特点，又因为他们属于不同的组织，不同的系统，也就构成了树形的结构，形成了目录，这样的话，在匹配用户名和密码时，就可以做到高效的检索

6.认证协议清单

充分利用主流认证策略的优点，认证系统融合多种认证协议，第三方生产系统可以选择自己支持的认证协议进行身份接入，减少实施过程中的协调成本。

6.1支持认证协议–CAS

CAS（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的交互而已。

术语解释：

Ticket-granting cookie(TGC)：存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证；

Service ticket(ST)：服务票据，服务的惟一标识码,由CAS Server发出（Http传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的ST；

Proxy-Granting ticket（PGT）：由CAS Server颁发给拥有ST凭证的服务，PGT绑定

一个用户的特定服务，使其拥有向CAS Server申请，获得PT的能力；

Proxy-Granting Ticket I Owe You（PGTIOU）:作用是将通过凭证校验时的应答信息由

CAS Server 返回给CAS Client，同时，与该PGTIOU 对应的PGT 将通过回调链接传给Web

应用。Web 应用负责维护PGTIOU 与PGT 之间映射关系的内容表；

Proxy Ticket (PT)：是应用程序代理用户身份对目标程序进行访问的凭证；

Ticket Granting ticket(TGT)：票据授权票据，由KDC 的AS 发放。即获取这样一张票

据后，以后申请各种其他服务票据(ST)便不必再向KDC 提交身份认证息(Credentials)；

Authentication service(AS)：认证用服务，索取Credentials，发放TGT；

Ticket-granting service (TGS)：票据授权服务，索取TGT，发放ST；

KDC(Key Distribution Center )：密钥发放中心；

6.2支持认证协议–OAUTH2.0

OAuth2.0是OAuth 协议的下一版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。

OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP 服务商之间的

被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web

应用，桌面应用和手机，和设备提供专门的认证流程。

目前微信、微博、twitter 等主流社交应用都采用OAUTH2.0的认证授权协议。CAS 服务

基于标准的Oauth2.0协议，具体认证流程请参考相关文档。https://https://www.360docs.net/doc/67970374.html,/2。

返回类型：接口地址描述请求方

式

/cas/oauth2.0/aut horize

用户请求授权，CAS 服务端开始认证流程

GET /cas/oauth2.0/acc essToken

获取access token ，以JSON 方式或文本形式返回

POST /cas/oauth2.0/pro file

通过回传上步获取的access token 来获取用户的其他信息

GET

基于Oauth2.0协议，CAS服务提供了如下的响应类型：

1、Authorization Code(授权码):

授权码方式可以提供给用户统一的用户认证界面。

/cas/oauth2.0/authorize?response_type=code&client_id=ID&redirect_uri=CALLBA CK

成功后会回调redirect_uri地址，并携带code参数。

/cas/oauth2.0/accessToken?grant_type=authorization_code&client_id=ID&client _secret=SECRET&code=CODE&redirect_uri=CALLBACK

成功后回调recirect_uri地址，并携带access_token

Token(令牌):

令牌方式可以提供给用户交互界面和非交互界面。

/cas/oauth2.0/authorize?response_type=token&client_id=ID&redirect_uri=CALLB ACK

成功后回调recirect_uri地址，并携带access_token。

3、password(密码):

密码方式可以让客户端直接发送用户名密码来取得用户凭证。

/cas/oauth2.0/accessToken?grant_type=password&client_id=ID&username=USERNAM E&password=PASSWORD

成功后返回access_token。

4、Refresh Token(令牌刷新):

当先前的令牌过期时，令牌刷新方式可以获取先前返回的refresh token来返回新的令牌。

/cas/oauth2.0/accessToken?grant_type=refresh_token&client_id=ID&client_secr et=SECRET&refresh_token=REFRESH_TOKEN

成功后返回access_token。

6.3支持认证协议–Remote Address

Authentication(远程地址认证)远程地址认证通过获取客户端地址来对用户认证，服务端通过配置IP范围来验证用户身份。

6.4支持认证协议–OPENID

OpenID是一个以用户为中心的数字身份识别框架，它具有开放、分散性。它的创建基于这样一个概念：我们可以通过URI（又叫URL或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。由于URI是整个网络世界的核心，它为基于URI的用户身份认证提供了广泛的、坚实的基础。

OpenID 系统的第一部分是身份验证，即如何通过URI 来认证用户身份。目前的网站都是依靠用户名和密码来登录认证，这就意味着大家在每个网站都需要注册用户名和密码，即便你使用的是同样的密码。如果使用OpenID ，你的网站地址（URI）就是你的用户名，而你的密码安全的存储在一个OpenID 服务网站上（你可以自己建立一个OpenID 服务网站，也可以选择一个可信任的OpenID 服务网站来完成注册）。

6.5支持认证协议–REST Protocal

(REST API)

REST 认证协议客户端通过向服务器发送REST 请求来获取用户认证信息。

认证流程：

1、请求TGT

成功响应12201Created

Location:https://www.360docs.net/doc/67970374.html,/cas/v1/tickets/{TGT id }

失败响应

如果验证失败，服务端将返回400；如果发送的http 类型不能识别，服务端将返回415。

2、请求ST

成功响应

失败响应

如果验证失败，服务端将返回400；如果发送的http 类型不能识别，服务端将返回415。

3、退出登录

12200OK

ST-1-FFDFHDSJKHSDFJKSDHFJKRUEYREWUIFSD2132

1DELETE/cas/v1/tickets/TGT-fdsjfsdfjkalfewrihfdhfaie HTTP/1.0

4、票据状态

1GET/cas/v1/tickets/TGT-fdsjfsdfjkalfewrihfdhfaie HTTP/1.0

成功响应

1200OK

失败响应

1404NOT FOUND

6.6支持认证协议–Digest Authentication

摘要认证（Digest authentication）用来提供比基础认证更高级别的安全。在RFC2617中有关于它的描述，摘要认证是一种基于挑战-应答模式的认证模型。

摘要认证与基础认证的工作原理很相似，用户先发出一个没有认证证书的请求，Web服务器回复一个带有WWW-Authenticate头的响应，指明访问所请求的资源需要证书。但是和基础认证发送以Base64编码的用户名和密码不同，在摘要认证中服务器让客户选一个随机数（称作”nonce“），然后浏览器使用一个单向的加密函数生成一个消息摘要（message digest），该摘要是关于用户名、密码、给定的nonce值、HTTP方法，以及所请求的URL。消息摘要函数也被称为散列算法，是一种在一个方向上很容易计算，反方向却不可行的加密算法。与基础认证对比，解码基础认证中的Base64是很容易办到的。在服务器口令中，可以指定任意的散列算法。在RFC2617中，描述了以MD5散列函数作为默认算法。

下图为摘要认证的原理流程图：

6.7支持认证协议–SAML

SAML（Security Assertion Markup Language）是一个XML框架，也就是一组协议和规范，可以用来传输企业用户身份证明，主要是企业外的身份跨域传递。比如，学校（idp）的用户要访问第三方应用（sp），为了保证身份安全，我们可以采用除了加密签名等措施，还要采用SAML规范来传输，传输的数据以XML形式，内容符合SAML的推荐标准，这样我们就可以不要求idp和sp采用什么样的系统，只要求能理解SAML规范即可，显然比传统的方式更好。SAML规范是一组Schema定义。

可以这么说，在Web Service领域，schema就是规范。SAML主要包括三个方面：

?认证申明。表明用户是否已经认证，通常用于单点登录。

?属性申明。表明某个主题的属性。

?授权申明。表明某个资源的权限。

7.用户登录鉴别过程

移动互联网时代，如何给用户更好的使用体验是我们设计的核心。我们力求让用户用最简单的方式登录到各个业务系统。卓云身份认证系统支持传统的用户名密码鉴别方式，也支持二维码、指纹识别等方式，且鉴别方式接口开发。

8.互联网认证拓展

利用互联网工具也可以进行身份认证，比如：微信登录、微博登录等。充分利用互联工具进行系统登录授权好处有三点：

第一：可以提升用户体验，更符合年表人的使用习惯。

第二：可以节约校方自己的基础设施资源。

第三：可以变向获取用户的社交账号，为未来进行全面的校情数据分析提供便利

9.基础设施资源

9.1配置清单

以下配置可以持并发数10000+，数据库服务器和LDAP服务器以物理机为主，或者直联存储。

9.2网络拓扑