CAS入門

企業(yè)單點登錄 - CAS提供友好的開源社區(qū)，積極支持并為項目做出貢獻。雖然該項目植根于高級開放源代碼，但它已發(fā)展成為跨越財富500強企業(yè)和小型專用設備的國際受眾。

CAS為Web提供企業(yè)單點登錄服務：

  • 開放且文檔齊全的協(xié)議開源
  • Java服務器組件
  • 可插入的身份驗證支持（LDAP，數(shù)據(jù)庫，X.509,2-factor）
  • 支持多種協(xié)議（CAS，SAML） ，OAuth，OpenID）Java，.Net，PHP，Perl，Apache，uPortal和其他
  • 客戶端庫集成了uPortal，BlueSocket，TikiWiki，Mule，Liferay，Moodle等
  • 社區(qū)文檔和實現(xiàn)支持廣泛的采用者社區(qū)

資源鏈接

架構

cas架構圖

CAS服務器

CAS服務器是基于Spring Framework構建的Java servlet，其主要職責是通過頒發(fā)和驗證票證來對用戶進行身份驗證并授予對啟用CAS的服務（通常稱為CAS客戶端）的訪問權限。當服務器在成功登錄后向用戶發(fā)出票證授予票證（TGT）時，將創(chuàng)建SSO會話。使用TGT作為令牌，通過瀏覽器重定向，根據(jù)用戶的請求向服務發(fā)出服務票據(jù)（ST）。隨后通過反向信道通信在CAS服務器上驗證ST。

CAS客戶端

術語“CAS客戶端”在其通用使用中具有兩個不同的含義。 CAS客戶端是任何啟用CAS的應用程序，可以通過支持的協(xié)議與服務器通信。 CAS客戶端也是可以與各種軟件平臺和應用程序集成的軟件包，以便通過某種認證協(xié)議（例如CAS，SAML，OAuth）與CAS服務器通信。已經開發(fā)了支持許多軟件平臺和產品的CAS客戶。

平臺：

應用：

  • Outlook Web Application (ClearPass + .NET CAS Client)
  • Atlassian Confluence
  • Atlassian JIRA
  • Drupal
  • Liferay
  • uPortal

協(xié)議

客戶端通過幾種支持的協(xié)議與服務器通信。所有支持的協(xié)議在概念上都是相似的，但有些協(xié)議具有使其適用于特定應用程序或用例的特征或特征。例如，CAS協(xié)議支持委托（代理）身份驗證，SAML協(xié)議支持屬性釋放和單點注銷。

支持的協(xié)議：

組件

根據(jù)三層子系統(tǒng)描述CAS服務器是很有幫助的：

幾乎所有部署注意事項和組件配置都涉及這三個子系統(tǒng)。 Web層是與包括CAS客戶端在內的所有外部系統(tǒng)進行通信的端點。 Web層委托票務子系統(tǒng)生成CAS客戶端訪問的票證。 SSO會話開始于成功驗證時發(fā)出票證授予票證，因此票務子系統(tǒng)經常委托給驗證子系統(tǒng)。

認證系統(tǒng)通常僅在SSO會話開始時處理請求，盡管存在可以調用它的其他情況（例如，強制認證）。

Spring 框架

CAS使用Spring Framework的許多方面;最值得注意的是，Spring MVC和Spring Webflow。 Spring為核心CAS代碼庫以及部署者提供了完整且可擴展的框架;通過掛鉤CAS和Spring API擴展點，可以直接定制或擴展CAS行為。 Spring的一般知識有助于理解某些框架組件之間的相互作用，但并不是嚴格要求的。但是，用于配置CAS和Spring組件的基于XML的配置是安裝，定制和擴展的核心問題。通常使用XML的能力和特別是Spring IOC容器是CAS安裝的先決條件。

安裝要求

要求概覽：

  1. Java >=1.7
  2. 支持servlet規(guī)范的Servlet容器 >=3.0
  3. Apache Maven >=3.3
  4. 熟悉Spring框架
  5. 互聯(lián)網連接

根據(jù)配置組件的選擇，可能還有其他要求，例如LDAP目錄，數(shù)據(jù)庫和緩存基礎結構。但是，在大多數(shù)情況下，對于選擇具有明確硬件和軟件依賴性的組件的部署者來說，要求應該是不言而喻的。在任何其他要求不明顯的情況下，組件配置的討論應該提到系統(tǒng)，軟件，硬件和其他要求。

Servlet容器

CAS沒有官方支持的servlet容器，但Apache Tomcat是最常用的。對特定servlet容器的支持取決于社區(qū)成員的專業(yè)知識，但已知以下工作正常并且應該獲得社區(qū)討論郵件列表的優(yōu)先支持：

Apache Maven

CAS使用Maven構建和創(chuàng)建可部署的軟件包，以便安裝到Java servlet容器中。強烈建議使用Maven進行CAS安裝過程所需的配置管理。 CAS基本上是一個復雜的軟件產品，它嵌入并緊密集成到機構的軟件環(huán)境中。因此，它傾向于要求定制遠遠超出交鑰匙解決方案，并且集成要求往往會隨著時間的推移而變化。像Maven WAR overlay這樣的基于源的安裝過程為復雜和動態(tài)的需求提供了直接而靈活的解決方案。雖然它確實需要高昂的前期學習成本，但從長遠來看，它可以獲得許多好處

互聯(lián)網連接

任何基于Maven的項目的構建階段通常都需要Internet連接，包括用于安裝CAS的推薦Maven WAR覆蓋。 Maven通過搜索包含本地下載和安裝的工件（大多數(shù)情況下為jar文件）的在線存儲庫來解析依賴關系。雖然可以通過替換Maven配置設置來覆蓋此行為，但它被視為高級用法，不受支持。

克服CAS服務器上缺少Internet連接的常見解決方案是在具有Internet連接的專用構建主機上構建CAS。隨后將構建生成的cas.war文件復制到CAS服務器以進行部署。

安全指南

CAS是一種安全軟件，可為基于Web的應用程序提供基于Web的安全單點登錄。單點登錄在安全性和便利性方面提供了雙贏：它減少了對單個受信任憑證代理的密碼暴露，同時透明地提供對多個服務的訪問而無需重復登錄。 CAS的使用通常會改善安全環(huán)境，但是應該考慮幾種CAS配置，策略和部署問題以實現(xiàn)適當?shù)陌踩浴?/p>

系統(tǒng)安全注意事項

安全傳輸（https）

與CAS服務器的所有通信必須通過安全信道（即TLSv1）進行。此要求有兩個主要理由：

  1. 身份驗證過程需要傳輸安全憑據(jù)。
  2. CAS票證授予票證是不記名令牌。

由于任一數(shù)據(jù)的公開都會允許冒充攻擊，因此保護CAS客戶端和CAS服務器之間的通信通道至關重要。

實際上，這意味著所有CAS URL必須使用HTTPS，但這也意味著必須使用HTTPS完成從CAS服務器到應用程序的所有連接：

  1. 當生成的服務票據(jù)被發(fā)送回“服務”URL上的應用程序時。
  2. 當調用代理回調網址時。

與依賴系統(tǒng)的連接

CAS通常需要連接到其他系統(tǒng)，例如LDAP目錄，數(shù)據(jù)庫和緩存服務。我們通常建議在可能的情況下對這些系統(tǒng)使用安全傳輸（SSL / TLS，IPSec），但可能存在補償性控制，這使得安全傳輸成為必要。具有嚴格訪問控制的專用網絡和企業(yè)網絡是常見的例外情況，但仍建議使用安全傳輸?？蛻舳苏J證驗證可以是LDAP提供足夠安全性的另一個好方案。

如前所述，必須確保與其他系統(tǒng)的連接。但是，如果CAS服務器部署在多個節(jié)點上，則同樣適用于CAS服務器本身。如果基于緩存的故障單注冊表在單個CAS服務器上運行時沒有任何安全問題，則在網絡未受保護時使用多個節(jié)點時，同步可能會成為安全問題。

如果沒有正確保護，任何磁盤存儲也都容易受到攻可以關閉EhCache溢出到磁盤以增加保護，而高級加密數(shù)據(jù)機制應該用于數(shù)據(jù)庫磁盤存儲。

部署驅動的安全功能

CAS支持許多可用于實現(xiàn)各種安全策略的功能。通過CAS配置和CAS客戶端集成提供以下功能。請注意，許多功能都是開箱即用的，而其他功能則需要顯式設置。

強制認證

許多CAS客戶端和支持的協(xié)議支持強制身份驗證的概念，用戶必須重新進行身份驗證才能訪問特定服務。 CAS協(xié)議通過renew參數(shù)支持強制認證。強制身份驗證為SSO會話的主體身份提供了額外的保證，因為用戶必須在訪問之前驗證其憑據(jù)。強制認證適用于需要或強制要求更高安全性的服務。通常，強制身份驗證是基于每個服務配置的，但是服務管理工具通過集中安全策略為實施強制身份驗證提供了一些支持。強制認證可以與多因素認證特征組合以實現(xiàn)任意特定于服務的訪問控制策略。

被動認證

某些CAS協(xié)議支持被動身份驗證，其中在請求時匿名授予對受CAS保護的服務的訪問權限。 CASv2和CASv3協(xié)議通過網關功能支持此功能。被動認證補充了強制認證;強制身份驗證需要身份驗證才能訪問服務，被動身份驗證允許服務訪問，盡管是匿名的，無需身份驗證。

代理驗證

代理身份驗證或委派身份驗證提供了CAS的強大，重要且可能具有安全性的功能。 CASv2和CASv3協(xié)議支持代理身份驗證，并由代表用戶的服務請求的代理票證調解;因此，服務代理用戶的認證。代理身份驗證通常用于服務無法直接與用戶交互的情況，也可用作將最終用戶憑據(jù)重放到服務的替代方法。

然而，代理票據(jù)存在風險，因為接受代理票據(jù)的服務負責驗證代理鏈（最終用戶的認證已經被委托到達票證驗證服務的服務列表）。通過簡單地針對/ serviceValidate驗證端點驗證票證，服務可以完全選擇不接受代理票證（并避免驗證代理鏈的責任），但是經驗表明很容易對此進行混淆并配置為無意中使用/ proxyValidate端點不仔細檢查故障單驗證響應中出現(xiàn)的任何代理鏈。因此，代理身份驗證需要仔細配置以進行適當?shù)陌踩绻恍枰砩矸蒡炞C，建議在CAS服務器上禁用代理身份驗證組件。

過去，任何服務都可以獲取代理授予票證，并從中獲取代理票證以訪問任何其他服務。換句話說，安全模型是分散的而不是集中的。服務管理設施通過暴露可以基于每個服務啟用或禁用的代理驗證標志來提供對代理驗證的一些集中控制。默認情況下，注冊服務未授予代理身份驗證功能。

多因素身份驗證

CAS以兩種模式之一提供對多因素身份驗證的支持：全局和單服務。登錄表單上總是需要多個憑證的全局情況很簡單：修改用戶界面以接受多個憑證，并將身份驗證組件配置為要求成功驗證所有提供的憑據(jù)。

單服務案例更有趣，更復雜：

  • 必須建立憑證和憑證組的身份保證級別（LOA）。
  • 必須根據(jù)服務建立安全策略與憑證LOA。
  • 必須通過服務管理工具配置服務訪問策略。

前兩項任務至關重要，但超出了本文檔的范圍。通過服務管理工具應用服務訪問策略是通過聲明必須成功驗證憑證以允許訪問的驗證處理程序來實現(xiàn)的;例如，LDAP身份驗證處理程序和RSA SecureID身份驗證處理程序。

由于多因素身份驗證需要開發(fā)機構安全策略，高級組件配置（以及可能的自定義組件開發(fā)）和UI設計，因此應將其視為框架而非功能。有關配置問題和實施建議的詳細討論，請參閱多因素配置部分。

憑據(jù)緩存和恢復

ClearPass擴展提供了一種機制，用于捕獲主要身份驗證憑據(jù)，對其進行緩存（加密），并根據(jù)需要恢復以訪問舊服務。雖然建議使用代理身份驗證代替密碼重放，但可能需要將舊服務與CAS集成。有關詳細信息，請參閱ClearPass文檔。

安全響應標頭

作為CAS安全篩選器的一部分，CAS項目自動提供必要的配置，以將HTTP安全標頭插入Web響應中，以防止HSTS，XSS，X-FRAME和其他攻擊。默認情況下，這些設置目前處于關閉狀態(tài)，可通過以下設置啟用：

# httpresponse.header.cache=false
# httpresponse.header.hsts=false
# httpresponse.header.xframe=false
# httpresponse.header.xcontent=false
# httpresponse.header.xss=false

要查看并了解有關這些選項的更多信息，請訪問此指南。

高可用性指南(HA /群集)

高度可用的CAS部署是為了響應各種故障模式而提供彈性的部署，以便盡管出現(xiàn)故障，CAS仍繼續(xù)提供SSO服務。我們提供推薦的體系結構，為規(guī)劃和執(zhí)行符合機構性能和可用性要求的CAS部署提供了一個起點。它還提供了一個框架，用于理解由HA考慮因素強加的CAS軟件組件要求。

通過確保有足夠的冗余來實現(xiàn)CAS的高可用性（HA）配置，以便在面對組件故障時服務是穩(wěn)健的，并且可以在沒有服務停機的情況下完成日常維護。這可以通過多節(jié)點實現(xiàn)，在較小程度上可以通過具有高級虛擬機功能的單節(jié)點CAS實現(xiàn)。本文檔將重點介紹實現(xiàn)HA所需的CAS Server組件。對HA配置的更加定量的分析取決于支持基礎設施和服務，超出了本文檔的范圍。

CAS服務器軟件具有非常可靠的良好記錄。但是，CAS服務器只是軟件和硬件的一小部分，認證必須遍歷才能順利運行。集群通常使用集群，不僅用于負載處理，還用于故障轉移。即使沒有發(fā)生故障，有時也需要重新啟動服務器。例如，如果安裝了操作系統(tǒng)級別的嚴重安全修復程序，則應立即重新啟動服務器。在CAS服務器集群中，即使在最繁忙的時間，也可以通過滾動重啟輕松完成。

傳統(tǒng)上操作單個服務器會延遲重啟，直到較不繁忙的時間，同時運行已知漏洞。然而，最近隨著虛擬機技術的日益接受及其固有的冗余和容錯性，單節(jié)點CAS已經能夠實現(xiàn)類似的質量。

推薦架構

下圖突出顯示了高可用CAS部署的重要方面。

CAS集群架構

值得指出這種架構的一些重要特征：

  • 從屬系統(tǒng)可以容忍多達N-1個節(jié)點故障。 （其中N是節(jié)點總數(shù)。）
  • CAS本身可以容忍多達N-1個節(jié)點故障。
  • 丟失緩存節(jié)點不會導致復制緩存中的SSO狀態(tài)數(shù)據(jù)（即票據(jù)）丟失。
  • 丟失緩存節(jié)點可能導致非復制緩存中的SSO狀態(tài)數(shù)據(jù)丟失（例如，memcached）。
  • SSO狀態(tài)數(shù)據(jù)的丟失始終是優(yōu)雅的：用戶只需重新進行身份驗證。

在詳細討論推薦架構的各個方面之前，我們提供了規(guī)劃高可用性部署的指導原則：

追求簡單
設計滿足性能和可用性要求的最簡單解決方案。

經驗表明，簡單性是成功和強大的HA部署的重要系統(tǒng)特征。力求簡潔，您將獲得良好的服務。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容