趙 晉，楊旭東

(北京郵電大學(xué) 計算機學(xué)院，北京 100876)

基于CAS的單點登錄系統(tǒng)的研究與實現(xiàn)

趙 晉，楊旭東

(北京郵電大學(xué) 計算機學(xué)院，北京 100876)

隨著互聯(lián)網(wǎng)的發(fā)展，用戶經(jīng)常需要訪問不同系統(tǒng)，這就導(dǎo)致用戶需要頻繁登錄。單點登錄就是為解決上述問題而提出的一種技術(shù)，它可以使用戶只登錄某個系統(tǒng)一次即可訪問所有相關(guān)的應(yīng)用系統(tǒng)。本文在分析了CAS協(xié)議的基本原理后，實現(xiàn)了基于CAS的單點登錄系統(tǒng)，為CAS服務(wù)器端添加了訪問權(quán)限控制、緩存層和基于Netty的用戶管理系統(tǒng)的功能。

軟件工程；單點登錄；CAS；統(tǒng)一認證

本文著錄格式：趙晉，楊旭東. 基于CAS的單點登錄系統(tǒng)的研究與實現(xiàn)[J]. 軟件，2016，37（11）：118-124

0 引言

隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡(luò)中提供服務(wù)的增多，人們?nèi)粘Ｉ钏枰男畔①Y源也隨之增多。在這種條件下，用戶經(jīng)常需要訪問一個內(nèi)部網(wǎng)絡(luò)中的多種不同子系統(tǒng)中的資源，由于不同系統(tǒng)的軟硬件平臺在初期設(shè)計時沒有統(tǒng)一的訪問標準和安全策略，導(dǎo)致用戶在訪問各個子系統(tǒng)時都需要進行獨立的身份認證。這就要求用戶需要記住自己在不同系統(tǒng)的身份標志，例如用戶名和訪問密碼等，并且當(dāng)需要訪問多個系統(tǒng)時，需要反復(fù)驗證用戶身份，這無疑會對用戶體驗造成影響，并且降低了各系統(tǒng)的易用性。為了應(yīng)對以上問題，產(chǎn)生了單點登錄(Single sign-on，簡稱為SSO)系統(tǒng)。

單點登錄的定義是在多個應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)[1]。統(tǒng)一認證是單點登錄的一種解決方案，統(tǒng)一認證的主要思路就是由唯一一個統(tǒng)一認證系統(tǒng)接管各個不同系統(tǒng)的身份認證模塊，各應(yīng)用系統(tǒng)只需要通過統(tǒng)一認證系統(tǒng)所系統(tǒng)的信息即可實現(xiàn)用戶身份的驗證[2]。

JASIG-CAS本身為Yale大學(xué)開發(fā)，后轉(zhuǎn)入JASIG項目。它是一個單點登錄系統(tǒng)的框架，它基于統(tǒng)一認證，并且支持跨域訪問。同時本身即可作為一個獨立的WEB應(yīng)用程序運行使用，內(nèi)部使用Spring Web Flow和Spring MVC框架實現(xiàn)。它包括一個JAVA開源服務(wù)器組件，并提供多種官方和非官方的客戶端組件，官方的客戶端組件包括JAVA、.NET、PHP和Apache。并且CAS支持多種協(xié)議和存儲后端，比如自己獨有的CAS協(xié)議、OpenID協(xié)議、SAML協(xié)議、OAuth協(xié)議等，存儲后端有數(shù)據(jù)庫、LDAP、Active Directory等。并且CAS在全球有很多大學(xué)和企業(yè)在使用，認可度較高。

本文使用CAS框架來實現(xiàn)單點登錄系統(tǒng)，并完善了單點登錄系統(tǒng)，使其增加了粗細兩種用戶訪問

控制機制、緩存層和基于Netty 的用戶管理系統(tǒng)，用戶管理系統(tǒng)包含注冊服務(wù)器、管理服務(wù)器和基于Netty的WebSocket服務(wù)器，使得管理者無需刷新用戶管理系統(tǒng)頁面即可獲取到用戶信息。

粗粒度訪問控制機制使用Mybatis框架實現(xiàn)，細粒度訪問控制機制使用shiro實現(xiàn)，緩存層使用了Redis數(shù)據(jù)庫，用戶管理系統(tǒng)使用了Netty作為WebSocket服務(wù)器，用于轉(zhuǎn)發(fā)和推送消息，數(shù)據(jù)庫使用了MySQL。

1 本文采用的方案

先介紹一下CAS框架的主要協(xié)議，即CAS協(xié)議。

CAS協(xié)議是JASIG-CAS特有的基于票據(jù)的協(xié)議（ticket-based protocol），它實現(xiàn)簡單而且功能強大。它涉及到一個或多個CAS客戶端和一個CAS服務(wù)器。其中CAS服務(wù)器負責(zé)驗證用戶身份并授予訪問權(quán)限。CAS客戶端的作用是保護Web應(yīng)用并從CAS服務(wù)器獲取已授予訪問權(quán)限的用戶身份。

TGT（Ticket Granting Ticket）票據(jù)被存儲于名為CASTGC的cookie中，它是已通過CAS服務(wù)器身份認證的用戶標志。ST (Service Ticket) 票據(jù)通過HTTPS協(xié)議的Get方式傳輸，即URL傳參，它是用戶訪問特定Web應(yīng)用的許可標志 。

CAS協(xié)議實現(xiàn)原理如下圖1所示：

用戶第一次訪問應(yīng)用1時的步驟：

1. 用戶通過瀏覽器向受到CAS客戶端保護的Web應(yīng)用1發(fā)出請求。

2. CAS客戶端檢測到這次訪問還未被授權(quán)，即沒有在cookie中檢測到session id，之后將此次請求轉(zhuǎn)發(fā)到CAS服務(wù)器。

圖1 用戶首次訪問應(yīng)用1的過程Fig.1 The process of user’s first visit of application 1.

3. CAS服務(wù)器檢測到用戶cookie中沒有TGT票據(jù)信息，所以向用戶瀏覽器返回登錄界面。

4. 用戶輸入身份信息，并利用POST方式將信息發(fā)送到CAS服務(wù)器。

5. CAS服務(wù)器驗證身份信息，驗證通過后，創(chuàng)建TGT票據(jù)并將TGT票據(jù)保存到用戶cookie中。之后創(chuàng)建ST票據(jù)，并將ST票據(jù)信息寫入到用戶瀏覽器即將轉(zhuǎn)發(fā)的URL的參數(shù)中。該URL指向之前用戶請求訪問的受CAS客戶端保護的Web應(yīng)用1。

6. CAS客戶端向CAS服務(wù)器發(fā)出校驗ST票據(jù)的請求。

7. CAS服務(wù)器驗證ST票據(jù)信息成功，之后創(chuàng)建并返回一個包含成功信息和其他所需參數(shù)的XML文檔給受CAS客戶端保護的Web應(yīng)用1。

8. CAS客戶端建立session，并將session id寫入到用戶cookie中。最后將需要轉(zhuǎn)發(fā)的去除了ST票據(jù)信息的URL返回給用戶瀏覽器。該URL即為用戶最初請求的URL。

圖2 用戶再次訪問應(yīng)用1的過程Fig.2 The process of user’s second visit of application 1.

圖3 用戶訪問應(yīng)用2時的過程Fig.3 The process of user’s first visit of application 2

9. 用戶瀏覽器再次請求訪問Web應(yīng)用1。

10. CAS客戶端在cookie中檢測到session id，允許訪問。

11. Web應(yīng)用1返回資源給用戶瀏覽器，如圖2所示。

用戶再次訪問應(yīng)用1時的步驟：

1. 用戶通過瀏覽器向受到CAS客戶端保護的Web應(yīng)用1發(fā)出請求。

2. CAS客戶端在cookie中檢測到session id，允許訪問。

3. Web應(yīng)用1返回資源給用戶瀏覽器，如圖3所示。

用戶接下來訪問應(yīng)用2時的步驟：

1. 用戶通過瀏覽器向受到CAS客戶端保護的Web應(yīng)用2發(fā)出請求。

2. CAS客戶端檢測到這次訪問還未被授權(quán)，即沒有在cookie中檢測到session id，之后將此次請求轉(zhuǎn)發(fā)到CAS服務(wù)器。

3. CAS服務(wù)器在用戶cookie中發(fā)現(xiàn)TGT票據(jù)信息，驗證TGT信息成功后，創(chuàng)建ST票據(jù)，并將ST票據(jù)信息寫入到用戶瀏覽器即將轉(zhuǎn)發(fā)的URL的參數(shù)中。該URL指向之前用戶請求訪問的受CAS客戶端保護的Web應(yīng)用2。

4. CAS客戶端向CAS服務(wù)器發(fā)出校驗ST票據(jù)的請求。

5. CAS服務(wù)器驗證ST票據(jù)信息成功，之后創(chuàng)建并返回一個包含成功信息和其他所需參數(shù)的XML文檔給受CAS客戶端保護的Web應(yīng)用2。

6. CAS客戶端建立session，并將session id寫入到用戶cookie中。最后將需要轉(zhuǎn)發(fā)的去除了ST票據(jù)信息的URL返回給用戶瀏覽器。該URL即為用戶最初請求的URL。

7. 用戶瀏覽器再次請求訪問Web應(yīng)用2。

8. CAS客戶端在cookie中檢測到session id，允許訪問。

9. Web應(yīng)用2返回資源給用戶瀏覽器。

由于CAS框架本身不具備權(quán)限控制和用戶管理的功能，同時在訪問量很大，并發(fā)量很高的情況下，用戶很可能在某個時間內(nèi)連續(xù)登陸，這會對數(shù)據(jù)庫造成很大的壓力，可以添加一個緩存層來緩解數(shù)據(jù)庫的壓力。

本文采用Redis對單點登錄系統(tǒng)進行擴充，添加緩存層。同時修改CAS協(xié)議的源碼，在上述CAS協(xié)議的基礎(chǔ)上，對協(xié)議進行擴展，在生成ST票據(jù)?前添加粗粒度的訪問權(quán)限控制的功能，即是否有權(quán)訪問指定網(wǎng)站，同時對于每個網(wǎng)站內(nèi)的Web資源，利用Shiro添加了細粒度的訪問權(quán)限控制。最后，用戶管理系統(tǒng)使用Netty作為中間的WebSocket服務(wù)器，其作用是接收注冊服務(wù)器的信息并轉(zhuǎn)發(fā)到用戶管理系統(tǒng)服務(wù)器上。

單點登錄系統(tǒng)的服務(wù)器端和客戶端均在Ubuntu 14.04 Kylin系統(tǒng)下開發(fā)，服務(wù)器端使用CAS框架實現(xiàn)，版本為4.1.1，使用了MyBatis框架來改進CAS服務(wù)器，為其添加用戶控制訪問的功能，存儲后端使用數(shù)據(jù)庫驗證用戶信息，數(shù)據(jù)庫使用 MySQL5.6，并利用Redis數(shù)據(jù)庫為服務(wù)器添加了緩存層?？蛻舳耸褂昧薙hiro框架，并且Shiro集成了CAS客戶端。注冊服務(wù)器和用戶管理服務(wù)器使用了SSM(SpringMVC+ Spring+Mybatis)框架實現(xiàn)就，MVC的意思是模型-視圖-控制器，它是一種設(shè)計模式也是一種設(shè)計典范[3]。1WebSocket服務(wù)器使用了Netty實現(xiàn)。

2 CAS單點登錄系統(tǒng)的實現(xiàn)與改進

2.1 用戶訪問控制機制與Shiro

一般而言，用戶訪問控制機制包含以下四點：

1. 身份認證

2. 授權(quán)

3. 確定用戶權(quán)限

4. 執(zhí)行訪問

用戶訪問控制機制有兩個關(guān)鍵的概念。即客體(object)和主體(Subject)。

客體是一種信息實體，它們蘊含或接收信息，客體在Web應(yīng)用系統(tǒng)中通常指欲訪問的URL。主體也是一種實體，它能夠引起信息在客體間流動，主體在Web應(yīng)用系統(tǒng)中通常指用戶。

自主訪問控制(Discretionary Access Control, DAC)是最常用的一類訪問控制機制，是用來判斷一個主體是否有權(quán)訪問客體的一種約束機制。在這種機制下，一個主體(一般在Web應(yīng)用系統(tǒng)中指管理員)可以自主的說明其資源可以被那些其他主體(一般在Web應(yīng)用系統(tǒng)中指用戶)以何種訪問權(quán)限進行訪問。實現(xiàn)的方法有基于行或者基于列的兩種模式?；谛械淖灾髟L問控制機制在每個主體上都提供一個該主體可訪問的客體的明細表。而基于列的自主訪問機制，在每個客體上都提供一個可訪問它的主體的明細表[4]。

Shiro的內(nèi)部實現(xiàn)原理是基于自主訪問控制機

制，同時它的機制是基于列的形式。即需要對每一個客體指定可訪問它們的主體。

2.2 用戶訪問控制的實現(xiàn)

項目所采取的用戶訪問控制并不是完全依賴于Shiro，其中對應(yīng)用系統(tǒng)即CAS客戶端Web應(yīng)用的訪問控制是由修改過后的CAS服務(wù)器實現(xiàn)的，即粗粒度的訪問控制，而在CAS客戶端內(nèi)的更細粒度的訪問控制是由Shiro實現(xiàn)。這樣做的原因是因為：根據(jù)CAS協(xié)議原理，在用戶每次訪問CAS客戶端所保護的Web應(yīng)用時，若Session中無數(shù)據(jù)，則需要跳轉(zhuǎn)到CAS服務(wù)器，經(jīng)過一系列操作后才能再次訪問Web應(yīng)用，若由Shiro在客戶端實現(xiàn)訪問控制功能，則需要在CAS服務(wù)器的一系列操作后進行，之后若發(fā)現(xiàn)用戶無訪問權(quán)限，則上述在CAS服務(wù)器進行的操作都是沒有意義的。這就浪費了大量的資源和時間。

所以本項目在CAS服務(wù)器端修改源碼，在生成ST票據(jù)前讀取權(quán)限數(shù)據(jù)，判斷是否有權(quán)訪問，由CAS服務(wù)器來處理訪問控制。如下圖5所示：

圖5 訪問控制流程圖1Fig.5 flow-process diagram1 of Access Control

首先用戶訪問目標應(yīng)用系統(tǒng)，由于目標應(yīng)用系統(tǒng)受到CAS客戶端的保護，所以用戶將攜回調(diào)地址跳轉(zhuǎn)到CAS服務(wù)器，CAS服務(wù)器保存回調(diào)地址，并驗證用戶身份，若驗證失敗則禁止用戶訪問，若驗證成功則存儲用戶名到服務(wù)器端Session中，之后再在另外一個函數(shù)中從Session中讀取出用戶名，從數(shù)據(jù)庫中讀取出相應(yīng)權(quán)限信息，最后由之前保存的回調(diào)地址驗證是否有權(quán)限登錄，若無權(quán)限則返回，有權(quán)限則創(chuàng)建ST。

細粒度的訪問權(quán)限控制由客戶端的Shiro實現(xiàn)，即對Web應(yīng)用內(nèi)的某些特定資源進行訪問權(quán)限控制。該部分訪問流程如圖6所示：

首先用戶訪問受Shiro及CAS服務(wù)器保護的客戶端Web系統(tǒng)的指定Web資源，若客戶端不存在用戶信息需要向CAS服務(wù)器請求用戶信息，若存在用戶信息則從數(shù)據(jù)庫中讀取權(quán)限信息，之后若有權(quán)訪問則允許訪問，無權(quán)訪問則禁止訪問。

2.3 Redis緩存層的實現(xiàn)

CAS緩存層設(shè)計方面可以利用現(xiàn)在非常流行的NoSQL數(shù)據(jù)庫Redis來實現(xiàn)。它是一個基于key-value的存儲系統(tǒng)，并使用內(nèi)存存儲和讀取數(shù)據(jù)，并不是傳統(tǒng)意義的關(guān)系型數(shù)據(jù)庫。與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫相比，它具備極高的讀取性能，所以利用它作為緩存層是非常好的選擇。Redis的置換算法將使用LRU

算法，即在數(shù)據(jù)庫已滿時添加新數(shù)據(jù)，會將最近最少使用的數(shù)據(jù)淘汰。CAS存儲后端采用MySQL 5.6。

加入緩存層后的工作流程如圖7所示：

在用戶輸入用戶名和密碼后，瀏覽器將身份信息傳給CAS服務(wù)器。CAS服務(wù)器首先進行緩存層驗證，即讀取Redis數(shù)據(jù)庫中的用戶信息，若緩存命中且與用戶輸入相符，則創(chuàng)建TGT。否則，則從MySQL數(shù)據(jù)庫讀取用戶信息，若存在且與用戶輸入相符則先將用戶身份信息寫入Redis之后創(chuàng)建TGT，若用戶信息不存在或與用戶輸入不服則返回驗證失敗。

圖6 訪問控制流程圖2Fig.6 flow-process diagram2 of Access Control

圖7 緩存層工作流程圖Fig.7 flow-process diagram of Cache layer

2.4 基于Netty的用戶管理系統(tǒng)的實現(xiàn)

用戶管理系統(tǒng)包含注冊服務(wù)器、基于Netty的WebSocket服務(wù)器和管理服務(wù)器。其中注冊服務(wù)器用于完成用戶注冊，管理服務(wù)器實現(xiàn)用戶管理。這部分的工作流程圖如圖8所示：

首先，用戶訪問注冊服務(wù)器，請求注冊，注冊服務(wù)器判斷用戶輸入的信息是否合法，若不合法返回注冊失敗，若合法則完成注冊，之后將數(shù)據(jù)主動推送給基于Netty的WebSocket服務(wù)器，WebSocket服務(wù)器接受到數(shù)據(jù)后，再將數(shù)據(jù)主動推送給用戶管理服務(wù)器，將用戶信息展示并持久化到數(shù)據(jù)庫中。

當(dāng)管理員登錄系統(tǒng)，系統(tǒng)首先從數(shù)據(jù)庫中讀取數(shù)據(jù)，而后進行信息展示，等待接受WebSocket傳來的新的用戶信息，一旦有新用戶信息到來，利用Javascript修改頁面信息進行頁面展示，這樣做無需刷新頁面，管理員可以實時的獲取新用戶信息，并對用戶信息進行CRUD操作。

圖8 用戶管理系統(tǒng)工作流程圖Fig.8 flow-process diagram of User Administration

3 總結(jié)

本文在分析了CAS協(xié)議原理的基礎(chǔ)上，實現(xiàn)了一個基于CAS的單點登錄系統(tǒng)，并對其進行了改進，增加了粗細兩種訪問權(quán)限控制、緩存層和基于Netty和WebSocket的用戶管理系統(tǒng)。粗的訪問權(quán)限控制由Mybatis框架修改CAS服務(wù)器端源碼實現(xiàn)，緩存層由Redis實現(xiàn)，用戶管理系統(tǒng)利用了基于Netty的WebSocket服務(wù)器實現(xiàn)數(shù)據(jù)的主動推送，使得管理員無需刷新頁面即可獲取新的信息。之后未來的工作主要集中在系統(tǒng)性能的提高和魯棒性的提高上。

[1] 郭成寶. 基于Liferay 門戶與Lotus Domino OA 單點登錄系統(tǒng)的實現(xiàn)[J]. 軟件, 2014, 35(1): 72-74.

[2] 潛昕, 羅沙白, 盧康權(quán). 構(gòu)建基于分布式SOA架構(gòu)的統(tǒng)一身份認證體系[J]. 軟件, 2013, 34(1): 17-19[3]. 葛管庫.MVC模式下程序設(shè)計[J]. 軟件, 2013, 34(2): 49-51.

[3] 沈晴霓, 卿斯?jié)h. 操作系統(tǒng)安全設(shè)計[M]. 北京: 機械工業(yè)出版社, 2013.

[4] JASIG, CAS協(xié)議[OL]. https://apereo.github.io/cas/4.2.x/ protocol/CAS-Protocol.html.

[5] JASIG, CAS Protolcol[OL]. https://apereo.github.io/cas/4.2.x/ protocol/CAS-Protocol.html.

[6] 李俊. 一個基于JASIG-CAS改進的SSO模型及實現(xiàn)[D]. 四川: 電子科技大學(xué), 2011.

[7] 蘇悅洪. 基于CAS協(xié)議的單點登錄系統(tǒng)的研究與改進[D].廣州: 華南理工大學(xué), 2014.

A Research and Implementation of Single-Sign-On System based on CAS

ZHAO Jin YANG Xu-dong
(BeiJing University of Post and Telecommunications. Institute of Computer, BeiJing 100876)

With the development of the Internet,users often need to visit different systems,as a result,they need to login the systems frequently.Single-Sign-On(SSO) is a technology which can handle the problem above,users can lonin one system just once and then they can visit all relative systems without logging in again by using it.In this paper,after analyzing the basic of CAS protocol, SSO system based on CAS with the new functions of access control,cache layer and user administration is implemented.

Software engineering; Single-sign-on; CAS; Unified authentication

TP311.52

A

10.3969/j.issn.1003-6970.2016.11.026

趙晉(1990-)，男，碩士研究生，計算機軟件。

楊旭東，教授，主要研究方向：互聯(lián)網(wǎng)技術(shù)。