CAS實現單點登陸

時間 2019-12-02

標籤 cas 實現單點登陸简体版

原文原文鏈接

前言javascript

企業的信息化過程是一個按部就班的過程，在企業各個業務網站逐步建設的過程當中，根據各類業務信息水平的須要構建了相應的應用系統，因爲這些應用系統通常是在不一樣的時期開發完成的，各應用系統因爲功能側重、設計方法和開發技術都有所不一樣，也就造成了各自獨立的用戶庫和用戶認證體系。隨着新的業務網站不斷的增長，用戶在每一個應用系統中都有獨立的帳號，這樣就形成在訪問不一樣的應用系統時，須要記錄對應的用戶名和密碼，多個用戶名密碼極易記混，若是忘記或記錯了某一個業務網站的用戶名或密碼就沒法進行登陸，耽誤工做，影響工做效率，隨着局內信息化進程的推動還會有新的應用系統產生，若是不引入單一用戶登陸的解決方案，全公司工做人名特別是承擔審批權限的各級領導很難記清各種應用系統的用戶名和密碼，嚴重影響由信息化帶來快捷性和高效性。此外，多個應用平臺就有多個用戶管理，這也爲系統管理員維護人員系統帶來巨大的工做量，例如，一次變動10我的員，即便只有5個應用系統，也須要重複維護50我的員信息，而企業的每次人員調整遠不至10人，這種幾何增加的維護工做量，會浪費大量的精力和時間，減弱了信息化系統帶來方便快捷，爲此，需創建一套統一的、完善的、科學的單點登陸系統，每一個用戶只需記錄一個用戶名密碼，登陸一個平臺後便可實現各應用系統的透明跳轉，並且實行統一的用戶信息管理系統，系統管理員只需維護一套人員信息，更改信息經過平臺接口同步更新至各個應用系統，實現人員系統單次維護全公司同步變動，大大提升工做效率。php

新的應用系統在不斷開發，早一天規劃設計出單點登陸的規範接口，就能夠爲新開發的系統提出的一種整合的標準，在開發初期不管哪一個開發商，不管採用哪一種技術開發，只要遵循單點登陸的規範標準，新的系統開發完成以後便可無縫整合的到單點登陸平臺中，從而減小了系統開發完成後再整合到單點登陸改動而形成資源的浪費。css

從信息共享角度看現有的各個業務系統都使用各自的數據存儲方式，不通過基礎的用戶名和密碼認證後，相互之間沒法傳遞有效信息。爲避免信息孤島的產生，所以須要創建一個鏈接各個業務系統的技術架構和標準，實現平臺統一化整合；經過對業務處理和異常處理實現監管透明；經過將業務流程從應用中抽離，實現業務流程的靈活安排，這樣就須要一套能夠整合現有各個業務網站的信息共享平臺。java

單點登陸的英文名稱爲Single Sign-On，簡寫爲SSO，它是一個用戶認證的過程，容許用戶一次性進行認證以後，就訪問系統中不一樣的應用；而不須要訪問每一個應用時，都從新輸入密碼。IBM對SSO有一個形象的解釋「單點登陸、全網漫遊」。web

SSO將一個企業內部全部域中的用戶登陸和用戶賬號管理集中到一塊兒，SSO的好處顯而易見：spring

減小用戶在不一樣系統中登陸耗費的時間，減小用戶登陸出錯的可能性
實現安全的同時避免了處理和保存多套系統用戶的認證信息
減小了系統管理員增長、刪除用戶和修改用戶權限的時間
增長了安全性：系統管理員有了更好的方法管理用戶，包括能夠經過直接禁止和刪除用戶來取消該用戶對全部系統資源的訪問權限

對於內部有多種應用系統的企業來講，單點登陸的效果是十分明顯的。不少國際上的企業已經將單點登陸做爲系統設計的基本功能之一。sql

SSO的實現機制不盡相同，大致分爲Cookie機制和Session機制兩大類。數據庫

WebLogic經過Session共享認證信息。Session是一種服務器端機制，當客戶端訪問服務器時，服務器爲客戶端建立一個唯一的SessionID，以使在整個交互過程當中始終保持狀態，而交互的信息則可由應用自行指定，所以用Session方式實現SSO，不能在多個瀏覽器之間實現單點登陸，但卻能夠跨域。
WebSphere經過Cookie記錄認證信息。Cookie是一種客戶端機制，它存儲的內容主要包括: 名字、值、過時時間、路徑和域，路徑與域合在一塊兒就構成了Cookie的做用範圍，所以用Cookie方式可實現SSO，但域名必須相同。

CAS http://www.ja-sig.org/products/cas/，CAS單點登陸系統最先由耶魯大學開發。2004年12月，CAS成爲JA-SIG中的一個項目。JA-SIG的全稱是Java Architectures Special Interest Group，是在高校中推廣和探討基於Java的開源技術的一個組織。CAS的優勢不少，例如設計理念先進、體系結構合理、配置簡單、客戶端支持普遍、技術成熟等等。這也是咱們此次SSO改造的參照產品。apache

CAS 具備如下特色：windows

開源的企業級單點登陸解決方案。
CAS Server 爲須要獨立部署的 Web 應用。
CAS Client 支持很是多的客戶端(這裏指單點登陸系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
CAS 原理和協議

從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 須要獨立部署，主要負責對用戶的認證工做；CAS Client 負責處理對客戶端受保護資源的訪問請求，須要登陸時，重定向到 CAS Server。圖1 是 CAS 最基本的協議過程：

CAS Client 與受保護的客戶端應用部署在一塊兒，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每一個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket，若是沒有，則說明當前用戶還沒有登陸，因而將請求重定向到指定好的 CAS Server 登陸地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登陸成功事後轉回該地址。用戶在第 3 步中輸入認證信息，若是登陸成功，CAS Server 隨機產生一個至關長度、惟1、不可僞造的 Service Ticket，並緩存以待未來驗證，以後系統自動重定向到 Service 所在地址，併爲客戶端瀏覽器設置一個 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新產生的 Ticket 事後，在第 5，6 步中與 CAS Server 進行身份合適，以確保 Service Ticket 的合法性。

在該協議中，全部與 CAS 的交互均採用 SSL 協議，確保，ST 和 TGC 的安全性。協議工做過程當中會有 2 次重定向的過程，可是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。

以CAS爲例，使用Cookie實現單點登陸的原理圖如圖1所示。

首先，單點登陸分爲「服務端」和「客戶端」。服務端就是單點登陸服務器，而客戶端一般是「函數庫」或者「插件」。須要使用單點登陸的應用程序，須要把客戶端插件安裝到本身的系統中，或者將客戶端函數庫包括在代碼中。單點登陸的客戶端一般替換了原來應用程序的認證部分的代碼。
某個應用程序首先要發起第1次認證。大部分狀況下，應用程序中嵌入的客戶端會把應用程序原來的登陸畫面屏蔽掉，而直接轉到單點登陸服務器的登陸頁面。

圖 1 使用Cookie實現單點登陸的原理圖

用戶在單點登陸服務器的登陸頁面中，輸入用戶名和密碼。
而後單點登陸服務器會對用戶名和密碼進行認證。認證自己並非單點登陸服務器的功能，所以，一般會引入某種認證機制。認證機制能夠有不少種，例如本身寫一個認證程序，或者使用一些標準的認證方法，例如LDAP或者數據庫等等。在大多數狀況下，會使用LDAP進行認證。這是由於LDAP在處理用戶登陸方面，有不少獨特的優點，這在本文的後面還會比較詳細地進行介紹。
認證經過以後，單點登陸服務器會和應用程序進行一個比較複雜的交互，這一般是某種受權機制。CAS使用的是所謂的Ticket。具體這點後面還會介紹。
受權完成後，CAS把頁面重定向，回到Web應用。Web應用此時就完成了成功的登陸（固然這也是單點登陸的客戶端，根據返回的Ticket信息進行判斷成功的）。
而後單點登陸服務器會在客戶端建立一個Cookie。注意，是在用戶的客戶端，而不是服務端建立一個Cookie。這個Cookie是一個加密的Cookie，其中保存了用戶登陸的信息。
若是用戶此時但願進入其餘Web應用程序，則安裝在這些應用程序中的單點登陸客戶端，首先仍然會重定向到CAS服務器。不過此時CAS服務器再也不要求用戶輸入用戶名和密碼，而是首先自動尋找Cookie，根據Cookie中保存的信息，進行登陸。登陸以後，CAS重定向回到用戶的應用程序。

這樣，就再也不須要用戶繼續輸入用戶名和密碼，從而實現了單點登陸。

注意，這種單點登陸體系中，並無經過http進行密碼的傳遞（可是有用戶名的傳遞），所以是十分安全的。

CAS被設計爲一個獨立的Web應用，目前是經過若干個Java servlets來實現的。CAS必須運行在支持SSL的web服務器至上。應用程序能夠經過三個URL路徑來使用CAS，分別是登陸URL（login URL），校驗URL（validation URL）和登出URL（logout URL）。

應用程序一開始，一般跳過原來的登錄界面，而直接轉向CAS自帶的登陸界面。固然也能夠在應用程序的主界面上增長一個登陸之類的按鈕，來完成跳轉工做。
若是用戶喜歡的話，也能夠手工直接進入CAS的登陸界面，先進行登陸，在啓動其餘的應用程序。不過這種模式主要用於測試環境。
CAS的登陸界面處理所謂的「主體認證」。它要求用戶輸入用戶名和密碼，就像普通的登陸界面同樣。
主體認證時，CAS獲取用戶名和密碼，而後經過某種認證機制進行認證。一般認證機制是LDAP。
爲了進行之後的單點登陸，CAS向瀏覽器送回一個所謂的「內存cookie」。這種cookie並非真的保存在內存中，而只是瀏覽器一關閉，cookie就自動過時。這個cookie稱爲「ticket-granting cookie」，用來代表用戶已經成功地登陸。
認證成功後，CAS服務器建立一個很長的、隨機生成的字符串，稱爲「Ticket」。隨後，CAS將這個ticket和成功登陸的用戶，以及服務聯繫在一塊兒。這個ticket是一次性使用的一種憑證，它只對登陸成功的用戶及其服務使用一次。使用過之後馬上失效。
主體認證完成後，CAS將用戶的瀏覽器重定向，回到原來的應用。CAS客戶端，在從應用轉向CAS的時候，同時也會記錄原始的URL，所以CAS知道誰在調用本身。CAS重定向的時候，將ticket做爲一個參數傳遞回去。
例如原始應用的網址是http://www.itil.com/，在這個網址上，一開始有以下語句，轉向CAS服務器的單點登陸頁面https://secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx。
CAS完成主體認證後，會使用下面URL進行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
收到ticket以後，應用程序須要驗證ticket。這是經過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS服務器提供的。
CAS經過校驗路徑得到了ticket以後，經過內部的數據庫對其進行判斷。若是判斷是有效性，則返回一個NetID給應用程序。
隨後CAS將ticket做廢，而且在客戶端留下一個cookie。
之後其餘應用程序就使用這個cookie進行認證（固然經過CAS的客戶端），而再也不須要輸入用戶名和密碼。

0. 文檔介紹

0.1 文檔目的

0.2 文檔範圍

0.3 讀者對象

0.4 參考文獻

0.5 術語與縮寫解釋

1. 概述

1.1背景

1.2環境

1.3下載資源

2. 配置CAS SERVER

2.1簡單配置

2.2數據庫驗證配置

2.3HTTPS驗證配置

2.4HTTP驗證配置

2.5修改頁面

3. 配置JAVA CLIENT

3.1HTTPS驗證

3.2HTTP驗證

4. 配置DOTNET CLIENT

5. 配置PHP CLIENT

6. 如何實現單點註銷

0. 文檔介紹

0.1 文檔目的

記錄使用CAS實現SSO的過程。

0.2 文檔範圍

使用CAS實現SSO的過程。

0.3 讀者對象

任何有興趣的傢伙。

0.4 參考文獻

提示：列出本文檔的全部參考文獻（能夠是非正式出版物），格式以下：

[標識符] 做者，文獻名稱，出版單位（或歸屬單位），日期

大部分都是網絡上查詢的資料，不少，不列舉了。

0.5 術語與縮寫解釋

縮寫、術語	解釋
SSO	即Single sign on/off，單點登陸/退出
CAS	全稱JA-SIG Central Authentication Service，實現SSO的開源項目


…

1. 概述

1.1背景

單點登陸是必須的，實現方式頗多，這裏就說使用CAS的實現方式。使用CAS實現SSO，網絡上說明不少，大部分都是從製做證書開始，而其實是能夠不使用HTTPS驗證，這樣更方便。

單點登陸的原理是經過攔截你設定的URL，並跳轉到你指定的CAS SERVER登陸頁，當你登陸成功後，帶着TICKET，返回到你打開的URL。而後你就能夠一票在手，暢通無阻。

網上有個傢伙用旅遊的套票來解釋單點登陸，很是形象。當你到達一個旅遊區門口，你能夠買一個套票，套票規定你能夠遊覽N個景點，進入這些景點的時候，你不須要再買票，也就實現了單點登陸。

同時，也能夠借用這個比喻說明一下單點註銷。當你打開一個應用A時，單擊了註銷按鈕，跳轉到http://hostname:port/cas/logout 或者https://hostname:port/cas/logout ，系統顯示註銷成功。此時，IE窗口沒有關閉，你繼續打開應用A，仍然沒有註銷成功，不須要登陸。這就至關於你已經在旅遊景點內，即便你把套票撕毀了，你仍然能夠繼續參觀這個景點，不會把你驅逐出去。可是，你再也進不了其它的景點了。

那麼怎麼實現當即生效的註銷呢？或者這種方式是否就知足咱們的需求呢？

1.2環境

Windows XP、JDK1.7.0_4五、Tomcat7.0.27注意：安裝好環境。

A．在服務器上安裝JDK。

B．在服務器上安裝Tomcat

1.3下載資源

官網下載地址：http://downloads.jasig.org/cas-clients/

CAS服務器環境以下：32位系統

CAS服務器版本: cas-server-3.4.2.1-release

Jdk: jdk-7u45-windows-i586.exe

Tomcat: apache-tomcat-7.0.27.exe

cas-client-2.0.11.zip JAVA支持單點登陸

cas-client-3.1.8-release.zip JAVA支持單點註銷

dotnet-client-1.0.2-bin DOTNET客戶端

phpcas PHP客戶端

注意：同時要下載源代碼，部分功能（JAVAhttp協議）須要修改源代碼，從新作包。

2. 配置CAS SERVER

CAS SERVER目錄介紹。

2.1簡單配置

解壓縮下載下來的「cas-server-3.4.2.1-release.zip」，

在「modules」文件夾中找到「cas-server-webapp-3.4.2.1.war」，將其重命名爲「cas.war」

將「cas.war」拷貝到「%TOMCAT_HOME%\webapps」文件夾下。稍等一下子刷新一下，就會看到Tomcat自動將「cas.war」解壓到「cas」文件夾中。以下圖：

在默認配置下，CAS認爲只要用戶名密碼相同即登陸成功。咱們能夠經過修改配置以實現基於數據庫的身份驗證。不過目前咱們先以默認配置進行測試。

在瀏覽器中輸入網址「https://localhost:8443/cas/login」，若是IE有證書警告信息，直接點擊「繼續瀏覽此網站(不推薦)。

若是用戶名與密碼相同，則系統顯示登陸成功：

用戶能夠在瀏覽器中輸入網址「https://localhost:8443/cas/logout」，則系統自動完成註銷操做。

至此，服務器端配置所有完成。

2.2數據庫驗證配置

下載 Microsoft JDBC Driver for SQL Server。

（1）Microsoft JDBC Driver 4.0 for SQL Server 下載地址：http://www.microsoft.com/zh-cn/download/details.aspx?id=11774

網站提供了兩種格式文件供下載，一種是自解壓的EXE格式文件，還有一種是tar.gz格式的壓縮文件。兩種格式選其一下載便可，通過解壓縮，能夠獲得兩個JAR格式文件：sqljdbc.jar與sqljdbc4.jar。

（2）將「sqljdbc4.jar」拷貝至「%TOMCAT_HOME%\webapps\cas\WEB-INF\lib」文件夾。

（3）在以前從CAS網站下載「cas-server-3.5.1-release.zip」並解壓縮。在解壓縮的文件下中找到「modules\cas-server-support-jdbc-3.5.1.jar」,將其一併拷貝至「%TOMCAT_HOME%\webapps\cas\WEB-INF\lib」文件夾。

3.2.建立用於身份驗證的數據庫

（1）啓動SQL Server，新建一數據庫「UsersDB」，並在其中創建表「Users」，字段以下：

（2）在表中輸入若干測試數據：

3.3.配置CAS實現基於數據庫的身份驗證

（1）以管理員身份啓動文本編輯工具，打開「%TOMCAT_HOME%\webapps\cas\WEB-INF\deployerConfigContext.xml」。找到下面的代碼

<bean id="authenticationManager"

    class="org.jasig.cas.authentication.AuthenticationManagerImpl">

（2）在該段代碼前面插入 SQL Server JDBC 數據源配置信息：

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">

    <property name="driverClassName" value="com.microsoft.sqlserver.jdbc.SQLServerDriver"></property>

    <property name="url" value="jdbc:sqlserver://192.168.0.123:1433;databaseName=UsersDB"></property>

    <property name="username" value="sa"></property>

    <property name="password" value="123456"></property>

</bean>

以下圖所示：

（3）找到以下配置信息：

<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />

該配置信息使用SimpleTestUsernamePasswordAuthenticationHandler驗證用戶，即默認用戶名和密碼相同則驗證經過，用戶名密碼不一樣則登陸失敗。咱們須要將其替換成基於數據庫驗證的配置信息。

首先將上面的配置信息註釋掉，並在其下面插入以下配置信息：

<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">

    <property name="sql" value="select Password from users where username=?" />

    <property name="dataSource" ref="dataSource" />

</bean>

如圖所示：

說明：若是你安裝的是SQL Server 2008，那麼默認TCP/IP訪問協議不會打開，所以沒法經過IP地址的方式訪問SQL Server數據，解決辦法就是啓動SQL Server配置管理器，並在裏面啓用TCP/IP，啓用後記得從新啓動SQL Server服務以使設置生效。如圖所示：

（4）保存對「%TOMCAT_HOME%\webapps\cas\WEB-INF\deployerConfigContext.xml」所作的修改。

（5）從新啓動 Tomcat 服務。

(6) 打開CAS頁面進行測試

2.3 HTTPS驗證配置

（1）生成證書

在C盤根目錄下創建子文件夾「Keys」，用於存放證書。

單擊「開始 -> 運行"，輸入「cmd」，單擊「肯定」啓動命令提示符窗口。

輸入「cd "c:\Program Files\Java\jre7\bin"」進入jre7的bin目錄下。

執行命令建立證書。:「keytool -genkey -alias tomcat -keyalg RSA -storepass changeit -keystore c:\keys\.keystore -validity 3600」

注意：名字與姓氏要輸入主機名或域名或localhost，不能隨意輸入。密碼爲本身設定。下面的密碼直接回車。

如圖：

（2）將證書導入的JDK的證書信任庫中

第一步：導出證書。

執行命令「keytool -export -trustcacerts -alias tomcat -file c:\keys\tomcat.cer -keystore c:\keys\.keystore -storepass changeit」將證書導出到Keys文件夾。

第二步：將證書導入到JDK證書信任庫。

執行命令「keytool -import -trustcacerts -alias tomcat -file c:\keys\tomcat.cer -keystore "C:\Program Files\Java\jre7\lib\security\cacerts" -storepass changeit」。系統詢問是否信任此證書，回答「y」。

注意：這裏須要輸入密碼，此密碼不是前面設定的密碼，是系統默認的密碼changeit

其餘有用keytool命令（列出信任證書庫中全部已有證書，刪除庫中某個證書）：

keytool -list -v -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"

keytool -delete -trustcacerts -alias tomcat -keystore "C:\Program Files\Java\jre7\lib\security\cacerts" -storepass changeit

(3)配置server.xml文件(服務器須要https登錄驗證)

以管理員身份運行文字編輯器，打開%TOMCAT_HOME%\conf\server.xml。查找SSL配置並將以下內容插入其中。

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="C:/Keys/.keystore"

keystorePass="changeit" />

以下圖所示：

(4) 測試Tomcat上SSL是否配置成功

（A）重啓Tomcat服務。

（B）打開IE瀏覽器，分別測試「http://localhost:8080」和「https://localhost:8443/」

因爲此網站出具的安全證書不是由受信任的證書頒發機構頒發的，所以IE會有警告信息，這裏咱們直接點擊「繼續瀏覽此網站(不推薦)。」。

若是看到上面的界面，說明Tomcat的SSL配置成功。

2.4HTTP驗證配置(不須要製做證書)和修改COOKE時間

修改tomcat\webapps\cas\WEB-INF\deployerConfigContext.xml

增長參數p:requireSecure="false"，是否須要安全驗證，即HTTPS，false爲不採用，加上去以後以下：

Tomcat6.0\webapps\cas\WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml

參數p:cookieSecure="true"，同理爲HTTPS驗證相關，TRUE爲採用HTTPS驗證，與deployerConfigContext.xml的參數保持一致。

參數p:cookieMaxAge="-1"，簡單說是COOKIE的最大生命週期，-1爲無生命週期，即只在當前打開的IE窗口有效，IE關閉或從新打開其它窗口，仍會要求驗證。能夠根據須要修改成大於0的數字，好比3600等，意思是在3600秒內，打開任意IE窗口，都不須要驗證。

warnCookieGenerator.xml

兩個參數與上面同理。

TICKET的生命週期也能夠在web.xml加這個參數實現：

<context-param> <param-name>edu.yale.its.tp.cas.grantingTimeout</param-name>

<param-value>7200</param-value> </context-param>

2.5修改頁面

CAS頁面文件放在Tomcat 6.0\webapps\cas\WEB-INF\view\jsp中，頁面配置文件在Tomcat 6.0\webapps\cas\WEB-INF\classes中，好比default_views.properties，在這裏指定登陸用哪一個頁面，註銷用哪一個頁面等等。

在Tomcat 6.0\webapps\cas\WEB-INF\cas.properties文件指定使用哪一個皮膚頁面。

下面開始操做：

建議不要在原有的文件上進行修改，最好創建一份新的theme。

備份C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\cas

將cas項目複製，命名爲castest,咱們對castest項目進行修改

CAS登陸頁面存放在「%TOMCAT_HOME%\webapps\cas\WEB-INF\view\jsp\default\ui」文件夾下，該文件夾內有多個jsp文件，主要包括：

頁面	功能
casConfirmView.jsp	在瀏覽器跳轉到用戶想要訪問的頁面以前若是有警告信息，這個頁面將會被顯示。
casGenericSuccess.jsp	這個頁面通常不會被顯示，除非咱們直接訪問驗證服務器的驗證界面。
casLoginView.jsp	重點修改的頁面。這個就是輸入驗證信息的界面。
casLogoutView.jsp	註銷界面。
serviceErrorView.jsp	若是用戶想要訪問的服務沒有使用CAS，這個頁面將會顯示出來。注意：若是咱們全部的業務系統都使用了CAS，這個界面則會沒有任何做用。

上表所列頁面絕大多數無需修改，主要是「casLoginView.jsp」還有includes目錄下的「top.jsp」、「bottom.jsp」兩個文件。

具體辦法以下：

（1）使用瀏覽器調試工具（IE瀏覽器使用F12鍵）查看頁面結構，爲後續定義CSS文件作好準備。下圖顯示了登陸頁面的主體結構：

文檔分header、content、footer三部分，其中content內部又包括login和siderbar兩部份內容。若是在定義登陸頁面時須要調整網頁結構，記得CSS樣式的層級結構也一併加以修改。

（2）使用網頁編輯器編輯保存的離線網頁，在儘可能不修改頁面內容的條件下經過修改CSS樣式對登陸頁面加以調整。

casLoginView.jsp樣式文件:cas\css\cas.css 圖片路徑: cas\images js路徑: cas\js

(3) 保存所有修改。啓動Tomcat服務，測試下效果。有可能顯示原來的界面，可嘗試把「%TOMCAT_HOME%\work\Catalina」目錄下的文件夾清空掉再試。

下圖是通過加工後的CAS登陸頁面：

其它須要說明的地方：

（1）「%TOMCAT_HOME%\webapps\cas\js\cas.js」文件中「$(document).ready」方法包含了部分動畫顯示錯誤信息的javascript腳本，這能夠根據你頁面樣式的不一樣適當進行調整（主要是顏色）。

（2）在「%TOMCAT_HOME%\webapps\cas\WEB-INF\classes」文件夾下存在不少messages_*.properties文件，主要是爲了國際化。若是對頁面呈現的文字進行修改，能夠修改「messages_zh_CN.properties」文件中的信息。

2.6 密碼加密MD5

修改Tomcat 7.0\webapps\cas\WEB-INF deployerConfigContext.xml文件

<bean id="MD5PasswordEncoder"

class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder">

<constructor-arg index="0" value="MD5" />

</bean>

3. 配置JAVA CLIENT

3.1 HTTPS驗證

一、把casclient.jar、cas-client-3.1.8.jar複製到你的jsp工程的WEB-INF\lib裏；

二、修改web.xml，增長下面的代碼：

<listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>

</listener>

<filter-name>CAS Single Sign Out Filter</filter-name>

<filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>

</filter>

<filter-name>CAS Filter</filter-name>

<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>

<!—下面兩個爲驗證地址，即cas server的地址，若是使用https驗證，地址爲https://hostname:8443字樣- ->

<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>

<param-value>http://10.16.204.26:8443/cas/login</param-value>

</init-param>

<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>

<param-value>http://10.16.204.26:8443/cas/serviceValidate</param-value>

</init-param>

<!—本工程的URL，被攔截的地址- ->

<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>

<param-value>localhost:8080</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CAS Single Sign Out Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>CAS Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

三、在頁面得到驗證返回的用戶

用戶能夠經過如下方式，從JSP或servlet中獲取經過認證的用戶名：

String username = (String)session.getAttribute(edu.yale.its.tp.cas.client.filter.CASFilter.CAS_FILTER_USER);

得到更完整的受認證用戶信息對象CASReceipt Java Bean，可使用如下語句：

CASReceipt receipt = (CASReceipt )session.getAttribute(edu.yale.its.tp.cas.client.filter.CASFilter.CAS_FILTER_RECEIPT);

完成以上後，進行測試。出現錯誤時，請查看tomcat\logs文件解決。

3.2 HTTP驗證

找到客戶端使用的casclient.jar文件，借用反編譯工具將相應的class文件反編譯成java文件再進行下面的修改

一、找到edu.yale.its.tp.cas.client.filter.edu.yale.its.tp.cas.client.filter

Java代碼

if (! casValidate.startsWith("https://")){

throw new ServletException("validateUrl must start with https://, its current value is [" + casValidate + "]");

}

if (casServiceUrl != null){

if (! (casServiceUrl.startsWith("https://")|| (casServiceUrl.startsWith("http://") ))){

throw new ServletException("service URL must start with http:// or https://; its current value is [" + casServiceUrl + "]");

}

把這兩段內容註釋掉(此目錄下涉及修改的類文件有CASFilter.java、CASValidateFilter.java，其實全部的修改就是把與https有關的內容加以註釋)

二、找到edu.yale.its.tp.cas.util.SecureURL

Java代碼

if (!u.getProtocol().equals("https")){

// IOException may not be the best exception we could throw here

// since the problem is with the URL argument we were passed, not

// IO. -awp9

log.error("retrieve(" + url + ") on an illegal URL since protocol was not https.");

throw new IOException("only 'https' URLs are valid for this method");

}

把這段內容註釋掉

4. 配置ASP.NET CLIENT

1) 已配置版本:3.4.2.1的cas 服務端，URL地址：http://218.18.96.51:8443/cas/login，測試用戶及密碼：test

2) 須要從官網下載cas.net服務端dotnet-client-1.0.2-bin

3) 客戶端dll：DotNetCasClient.dll

4) 獲取用戶帳號的示例代碼：

Session["username"] = null;

if (!this.IsPostBack)

{

userName = (String)Session["username"];

if (string.IsNullOrEmpty(userName))

{

DotNetCASClientServiceValidate client = new DotNetCASClientServiceValidate();

userName = client.Authenticate(Request, Response, true);

}

Session["username"] = userName;

labUserName.Text = userName;

}

5) 將DotNetCasClient.dll導入到項目中

6) 修改web.xml 文件，添加如下代碼

</appSettings>

如圖所示:

在頁面的load事件中加入

Session["username"] = null;

if (!this.IsPostBack)

{

userName = (String)Session["username"];

if (string.IsNullOrEmpty(userName))

{

DotNetCASClientServiceValidate client = new DotNetCASClientServiceValidate();

userName = client.Authenticate(Request, Response, true);

}

Session["username"] = userName;

labUserName.Text = userName;

}

如圖所示:

編譯項目，併發布。

5. 配置PHP CLIENT

1）檢查php.ini文件中的extentions看curl和openssl是否打開，默認OA都是開啓的，如未開啓去掉「;」,並檢查相應的dll是否存在，php.ini文件通常存在OA安裝目錄BIN下。

2)下載php-cas客戶端，見webroot文件夾。主要有包含 cas.php和CAS文件夾，如圖所示：

調用方法：

核心思想：經過CAS客戶端的類獲取服務器的工號，而後OA只驗證工號，密碼無需驗證就能夠經過。

6. 如何實現單點註銷

經過http://10.16.204.26:8443/cas/logout?service=http://10.16.204.26:8443/cas/login 來實現

8.首頁顯示登陸信息

因爲CAS的封裝，咱們沒法獲取COOKies中信息，只能經過JS登陸時寫入信息到js中COOKies來實現

1. 登陸頁

修改casLoginView.jsp頁面，添加JS存入cookie

function setCookie(){

var username_str=document.getElementById("username").value;

var newcookie='usercode'+"="+username_str;

document.cookie=newcookie;

}

所下圖所示

2. 首頁

修改casGenericSuccess.jsp頁面，添加JS來獲取cookies顯示用戶信息

// 獲取指定名稱的cookie值

function getCookie(name){

var result = null;

var myCookie = document.cookie + ";";

var searchName = name + "=";

var startOfCookie = myCookie.indexOf(searchName);

var endOfCookie;

if (startOfCookie != -1)

{

startOfCookie += searchName.length;

endOfCookie = myCookie.indexOf(";",startOfCookie);

result = unescape(myCookie.substring(startOfCookie, endOfCookie));

}

return result;

}

document.getElementById('usercode').innerHTML='歡迎:'+ getCookie('usercode');

</script>

9.相關知識點

術語解釋：

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容請看SSL。它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL代表它使用了HTTP，但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通信方法，如今它被普遍用於萬維網上安全敏感的通信。
LDAP（全稱是Lightweight Directory Access Protocol），通常都簡稱爲LDAP。它是基於X.500標準的，可是簡單多了而且能夠根據須要定製。與X.500不一樣，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP的核心規範在RFC中都有定義，全部與LDAP相關的RFC均可以在LDAPman RFC網頁中找到。

簡單說來，LDAP是一個獲得關於人或者資源的集中、靜態數據的快速方式。LDAP協議是跨平臺的和標準的協議，所以應用程序就不用爲LDAP目錄放在什麼樣的服務器上操心了。實際上，LDAP獲得了業界的普遍承認，由於它是Internet的標準。產商都很願意在產品中加入對LDAP的支持，由於他們根本不用考慮另外一端（客戶端或服務端）是怎麼樣的。LDAP服務器能夠是任何一個開發源代碼或商用的LDAP目錄服務器（或者還多是具備LDAP界面的關係型數據庫），由於能夠用一樣的協議、客戶端鏈接軟件包和查詢命令與LDAP服務器進行交互。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。