cas跨域单点登录原理_CAS实现SSO单点登录原理
1.??????CAS?簡介
1.1.??What is CAS?？
CAS?(?Central Authentication Service?) 是?Yale?大學發起的一個企業級的、開源的項目，旨在為?Web?應用系統提供一種可靠的單點登錄解決方法(屬于?Web SSO?)。
CAS?開始于?2001?年， 并在?2004?年?12?月正式成為?JA-SIG?的一個項目。
1.2.??主要特性
1、???開源的、多協議的?SSO?解決方案；?Protocols?：?Custom Protocol?、?CAS?、?OAuth?、?OpenID?、?RESTful API?、?SAML1.1?、?SAML2.0?等。
2、???支持多種認證機制：?Active Directory?、?JAAS?、?JDBC?、?LDAP?、?X.509 Certificates?等；
3、???安全策略：使用票據(?Ticket?)來實現支持的認證協議；
4、???支持授權：可以決定哪些服務可以請求和驗證服務票據(?Service Ticket?)；
5、???提供高可用性：通過把認證過的狀態數據存儲在?TicketRegistry?組件中，這些組件有很多支持分布式環境的實現，如：?BerkleyDB?、?Default?、?EhcacheTicketRegistry?、?JDBCTicketRegistry?、?JBOSS TreeCache?、?JpaTicketRegistry?、?MemcacheTicketRegistry?等；
6、???支持多種客戶端：?Java?、?.Net?、?PHP?、?Perl?、?Apache, uPortal?等。
2.??????SSO?單點登錄原理
本文內容主要針對?Web SSO?。
2.1.??什么是SSO
單點登錄(?Single Sign-On ,?簡稱?SSO?)是目前比較流行的服務于企業業務整合的解決方案之一，?SSO?使得在多個應用系統中，用戶只需要?登錄一次就可以訪問所有相互信任的應用系統。
2.2.??SSO?原理
2.2.1.??????SSO?體系中的角色
一般?SSO?體系主要角色有三種：
1、?User?(多個)
2、?Web?應用(多個)
3、?SSO?認證中心(?1?個)
2.2.2.??????SSO?實現模式的原則
SSO?實現模式一般包括以下三個原則：
1、???所有的認證登錄都在?SSO?認證中心進行；
2、???SSO?認證中心通過一些方法來告訴?Web?應用當前訪問用戶究竟是不是已通過認證的用戶；
3、???SSO?認證中心和所有的?Web?應用建立一種信任關系，也就是說?web?應用必須信任認證中心。(單點信任)
2.2.3.??????SSO?主要實現方式
SSO?的主要實現方式有：
1、???共享?cookies
基于共享同域的?cookie?是?Web?剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞?cookies?機制，實現兩個域名之間系統令牌傳遞問題；另外，關于跨域問題，雖然?cookies本身不跨域，但可以利用它實現跨域的?SSO?。如：代理、暴露?SSO?令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、???Broker-based(?基于經紀人?)
這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用于進一步請求的電子身份存取。中央數據庫的使用減少了管理的代價，并為認證提供一個公共和獨立的?"第三方?"?。例如?Kerberos?、?Sesame?、?IBM KryptoKnight?(憑證庫思想?)?等。?Kerberos是由麻省理工大學發明的安全認證服務，已經被?UNIX?和?Windows?作為默認的安全認證服務集成進操作系統。
3、???Agent-based?(基于代理人)
在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在服務器上面，在服務器的認證系統和客戶端認證方法之間充當一個?"?翻譯?"。例如?SSH?等。
4、???Token-based
例如?SecureID,WebID?，現在被廣泛使用的口令認證，比如?FTP?、郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、???基于網關
6、???基于?SAML
SAML(Security Assertion Markup Language?，安全斷言標記語言)的出現大大簡化了?SSO?，并被?OASIS?批準為?SSO?的執行標準。開源組織?OpenSAML?實現了?SAML?規范。
3.??????CAS?的基本原理
3.1.??結構體系
從結構體系看，?CAS?包括兩部分：?CAS Server?和?CAS Client?。
3.1.1.??????CAS Server
CAS Server?負責完成對用戶的認證工作?,?需要獨立部署?,?CAS Server?會處理用戶名?/?密碼等憑證(Credentials)?。
3.1.2.??????CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到?CAS Server?進行認證。(原則上，客戶端應用不再接受任何的用戶名密碼等?Credentials?)。
CAS Client?與受保護的客戶端應用部署在一起，以?Filter?方式保護受保護的資源。
3.2.??CAS?原理和協議
3.2.1.??????基礎模式
基礎模式?SSO?訪問流程主要有以下步驟：
1.?訪問服務：?SSO?客戶端發送請求訪問應用系統提供的服務資源。
2.?定向認證：?SSO?客戶端會重定向用戶請求到?SSO?服務器。
3.?用戶認證：用戶身份認證。
4.?發放票據：?SSO?服務器會產生一個隨機的?Service Ticket?。
5.?驗證票據：?SSO?服務器驗證票據?Service Ticket?的合法性，驗證通過后，允許客戶端訪問服務。
6.?傳輸用戶信息：?SSO?服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。
下面是?CAS?最基本的協議過程：
基礎協議圖
如上圖：?CAS Client?與受保護的客戶端應用部署在一起，以?Filter?方式保護?Web?應用的受保護資源，過濾從客戶端過來的每一個?Web?請求，同時，?CAS Client?會分析?HTTP?請求中是否包含請求?Service Ticket( ST?上圖中的?Ticket)?，如果沒有，則說明該用戶是沒有經過認證的；于是?CAS Client?會重定向用戶請求到?CAS Server?(?Step 2?)，并傳遞?Service?(要訪問的目的資源地址)。?Step 3?是用戶認證過程，如果用戶提供了正確的?Credentials?，?CAS Server?隨機產生一個相當長度、唯一、不可偽造的?Service Ticket?，并緩存以待將來驗證，并且重定向用戶到?Service?所在地址(附帶剛才產生的?Service Ticket?)?,?并為客戶端瀏覽器設置一個?Ticket Granted Cookie?(?TGC?)；?CAS Client?在拿到?Service?和新產生的?Ticket?過后，在?Step 5?和?Step6?中與?CAS Server?進行身份核實，以確保?Service Ticket?的合法性。
在該協議中，所有與?CAS Server?的交互均采用?SSL?協議，以確保?ST?和?TGC?的安全性。協議工作過程中會有?2?次重定向的過程。但是?CAS Client?與?CAS Server?之間進行?Ticket?驗證的過程對于用戶是透明的(使用?HttpsURLConnection?)。
CAS?請求認證時序圖如下：
3.2.1.??????CAS?如何實現?SSO
當用戶訪問另一個應用的服務再次被重定向到?CAS Server?的時候，?CAS Server?會主動獲到這個?TGC cookie?，然后做下面的事情：
1)?如果?User?持有?TGC?且其還沒失效，那么就走基礎協議圖的?Step4?，達到了?SSO?的效果；
2)?如果?TGC?失效，那么用戶還是要重新認證?(?走基礎協議圖的?Step3)?。
3.2.2.??????CAS?代理模式
該模式形式為用戶訪問?App1?，?App1?又依賴于?App2?來獲取一些信息，如：?User -->App1 -->App2。
這種情況下，假設?App2?也是需要對?User?進行身份驗證才能訪問，那么，為了不影響用戶體驗(過多的重定向導致?User?的?IE?窗口不停地閃動?)?，?CAS?引入了一種?Proxy?認證機制，即?CAS Client?可以代理用戶去訪問其它?Web?應用。
代理的前提是需要?CAS Client?擁有用戶的身份信息?(?類似憑據?)?。之前我們提到的?TGC?是用戶持有對自己身份信息的一種憑據，這里的?PGT?就是?CAS Client?端持有的對用戶身份信息的一種憑據。憑借TGC?，?User?可以免去輸入密碼以獲取訪問其它服務的?Service Ticket?，所以，這里憑借?PGT?，?Web應用可以代理用戶去實現后端的認證，而?無需前端用戶的參與。
下面為代理應用(?helloService?)獲取?PGT?的過程：?(注：?PGTURL?用于表示一個?Proxy?服務，是一個回調鏈接；?PGT?相當于代理證；?PGTIOU?為取代理證的鑰匙，用來與?PGT?做關聯關系；)
如上面的?CAS Proxy?圖所示，?CAS Client在基礎協議之上，在驗證?ST?時提供了一個額外的PGT URL(?而且是?SSL?的入口?)?給?CAS Server?，使得?CAS Server?可以通過?PGT URL?提供一個?PGT?給?CAS Client?。
CAS Client?拿到了?PGT(PGTIOU-85?…?..ti2td)?，就可以通過?PGT?向后端?Web?應用進行認證。
下面是代理認證和提供服務的過程：
如上圖所示，?Proxy?認證與普通的認證其實差別不大，?Step1?，?2?與基礎模式的?Step1,2?幾乎一樣，唯一不同的是，?Proxy?模式用的是?PGT?而不是?TGC?，是?Proxy Ticket?(?PT?)而不是?Service Ticket?。
3.2.3.??????輔助說明
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?的交互而已。
3.3.??術語解釋
CAS?系統中設計了?5?中票據：?TGC?、?ST?、?PGT?、?PGTIOU?、?PT?。
??????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 ) ----------?密鑰發放中心；
4.??????CAS?安全性
CAS?的安全性僅僅依賴于?SSL?。使用的是?secure cookie?。
4.1.??TGC/PGT?安全性
對于一個?CAS?用戶來說，最重要是要保護它的?TGC?，如果?TGC?不慎被?CAS Server?以外的實體獲得，?Hacker?能夠找到該?TGC?，然后冒充?CAS?用戶訪問?所有授權資源。?PGT?的角色跟?TGC?是一樣的。
從基礎模式可以看出，?TGC?是?CAS Server?通過?SSL?方式發送給終端用戶，因此，要截取?TGC?難度非常大，從而確保?CAS?的安全性。
TGT?的存活周期默認為?120?分鐘。
4.2.??ST/PT?安全性
ST?(?Service Ticket?)是通過?Http?傳送的，因此網絡中的其他人可以?Sniffer?到其他人的?Ticket?。?CAS?通過以下幾方面來使?ST?變得更加安全(事實上都是可以配置的)：
1、???ST?只能使用一次
CAS?協議規定，無論?Service Ticket?驗證是否成功，?CAS Server?都會清除服務端緩存中的該Ticket?，從而可以確保一個?Service Ticket?不被使用兩次。
2、???ST?在一段時間內失效
CAS?規定?ST?只能存活一定的時間，然后?CAS Server?會讓它失效。默認有效時間為?5?分鐘。
3、???ST?是基于隨機數生成的
ST?必須足夠隨機，如果?ST?生成規則被猜出，?Hacker?就等于繞過?CAS?認證，直接訪問?對應的服務。
5.??????參考資料
1、?https://wiki.jasig.org/display/CASUM/Introduction
2、?http://www.jasig.org/cas/protocol/
3、?http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
4、?http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html
5、?http://baike.baidu.com/view/190743.htm
總結
以上是生活随笔為你收集整理的cas跨域单点登录原理_CAS实现SSO单点登录原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python long_python l
- 下一篇： dw上按钮事件 pb_「React TS