單點登錄方案說明書

單點登錄方案說明書擬制人：、日期：2015-7-9評審人：日期：批準(zhǔn)人：日期：修訂記錄日期版本修改章節(jié)修改描述作者2015-7-9V1.01初稿

目錄TOC\o"1-2"\h\z\u1 引言 41.1 方案綜述 41.2 參考資料 41.3 術(shù)語定義及說明 42 技術(shù)方案 42.1 方案一filter服務(wù) 42.2 方案二CAS 82.3 方案三OAuth 102.4 方案四SAML 112.5 方案五OpenID 13

單點登錄方案說明書引言方案綜述 下面介紹了五個主流的單點登錄技術(shù)，簡單概述一下每個技術(shù)的優(yōu)缺點： 方案一：屬于單獨創(chuàng)建的一個登錄服務(wù)，需集成的軟件登錄都需要繼承這個服務(wù)。實現(xiàn)單點登錄的要點在于，每個用戶登錄成功之后將生成一個ticket（票），每個程序通用這個ticket。方案二：CAS本身沒有授權(quán)，也沒有權(quán)限控制，但是CAS支持SAML，所以就支持了權(quán)限控制。方案三：OAUTH需要認證才可以獲取登錄權(quán)限，比較不適合我們情況方案四：SAML支持XACML協(xié)議進行權(quán)限控制。SAML協(xié)議較OAUTH來說確實比較復(fù)雜，但是功能也十分強大，支持認證，權(quán)限控制和用戶屬性。方案五：OpenID是IDP提供一個身份唯一標(biāo)識把第三方的應(yīng)用帳號綁定到唯一標(biāo)識上，只起到了認證的作用。參考資料 /alonesword/article/details/12190075 /Article/201312/268621.html /detail/48346-sso-%E7%99%BB%E5%BD%95 /link?url=ainiguhU2QB6PQCslL4nciBvux3UIzq50YUwSPEfoRntQOouVn-ks97xt8RCu9dlbQTJQvT0M8v0FjIBJZPY7aTx4ZVRTr1vy1xrGbszOCC術(shù)語定義及說明 SSO：SingleSignOn單點登錄 CAS：CentralAuthenticationService OAuth：OpenAuthorization開放授權(quán) SAML：SecurityAssertionMarkupLanguage安全斷言標(biāo)記語言技術(shù)方案方案一filter服務(wù)SSO實現(xiàn)方式，有一個SSOServer，也會叫認證中心。同時也會有被認證的系統(tǒng)，即client端系統(tǒng)。此方案中，Server端是自己構(gòu)建服務(wù)端，不依賴任何第三方技術(shù)。為了更形象體現(xiàn)SSO，我寫的SSO是有三個工程：一個SSOServer端口為8081，一個OA系統(tǒng)端口為8082，一個采購系統(tǒng)端口為8083。如圖：

流程介紹在整個SSO流程當(dāng)，有兩個流程非常重要，第一個是用戶沒有登錄系統(tǒng)到登錄系統(tǒng)的過程；第二是用戶在一個系統(tǒng)當(dāng)中已經(jīng)登錄（例如在OA系統(tǒng)中登錄了），但又想進入另一個系統(tǒng)（例如進入PRO系統(tǒng)）的過程，如果把這兩個過程搞定了，那么SSO也就搞定了。我畫了兩幅圖來說明這兩個過程。先看用戶沒有登錄系統(tǒng)到登錄系統(tǒng)的過程，如圖：

1：用戶通過URL訪問OA系統(tǒng)。2：在OA系統(tǒng)中的filter發(fā)現(xiàn)這個URL沒有ticket（你暫且就把ticket看做是門票），此時就會跳轉(zhuǎn)到SSOServer。3：SSOServer中的filter發(fā)現(xiàn)該客戶端中的cookie中沒有相應(yīng)信息，也即是一個沒有登錄的用戶，那么會跳轉(zhuǎn)到登錄頁面。4：用戶在登錄頁面填寫相應(yīng)信息，然后通過post方式提交到SSOServer中。5：SSOServer會校驗用戶信息（我為了快，我的校驗方式就是要用戶名為：cloud，同時密碼為：cloud），同時在cookie中放username。6：將生成ticket和username放到JVMCache中，在實際項目應(yīng)該放到Memcached中，它的用處等下分析。7，8：就是在用戶訪問OA系統(tǒng)的URL基礎(chǔ)上加上了一個ticket參數(shù)，這樣跳轉(zhuǎn)到OA系統(tǒng)。（此時進入OA系統(tǒng)時，filter發(fā)現(xiàn)URL是帶ticket的，則filter會根據(jù)帶過來的ticket并通過HttpClient的形式去調(diào)用SSOServer中的TicektServlet，這樣就會返回用戶名，其實這個用戶名就是從JVMCache拿到的，同時馬上將這個ticket從JVMCache中移除，這樣保證一個ticket只會用一次，然后把返回的用戶名放到session中）9：session中有了用戶名，說明用戶登錄成功了，則會去本應(yīng)該返問的servlet。10，11：將OA系統(tǒng)返回的視圖給用戶。第二過程，用戶已經(jīng)登錄成功了，但要訪問另一個系統(tǒng)，如圖：

1：用戶通過URL訪問PRO系統(tǒng)。2：在PRO系統(tǒng)中的filter發(fā)現(xiàn)這個URL沒有ticket，此時就會跳轉(zhuǎn)到SSOServer。此時，由于用戶登錄了，所以cookie中有相應(yīng)的信息（例如用戶名），此時SSOServer中的filter會生成一個ticket。3：將生成的ticket和username放到JVMCache中。4：就是在用戶訪問PRO系統(tǒng)的URL基礎(chǔ)上加上了一個ticket參數(shù)，這樣跳轉(zhuǎn)到PRO系統(tǒng)。（此時進入PRO系統(tǒng)時，filter發(fā)現(xiàn)URL是帶ticket的，則filter會根據(jù)帶過來的ticket并通過HttpClient的形式去調(diào)用SSOServer中的TicektServlet，這樣就會返回用戶名，其實這個用戶名就是從JVMCache拿到的，同時馬上將這個ticket從JVMCache中移除，這樣保證一個ticket只會用一次，然后把返回的用戶名放到session中）5：session中有了用戶名，說明用戶登錄成功了，則會去本應(yīng)該返問的servlet。5，7：將PRO系統(tǒng)返回的視圖給用戶。方案二CAS此方案是依賴于CAS技術(shù)基礎(chǔ)之上的，所謂的CAS是指的是：全拼是CentralAuthenticationService，是Yale大學(xué)發(fā)起的構(gòu)建WebSSO的Java開源項目。CAS的結(jié)構(gòu)體系CASServerCASServer負責(zé)完成對用戶信息的認證，需要單獨部署，CASServer會處理用戶名/密碼等憑證(Credentials)。CASClientCASClient部署在客戶端，當(dāng)有對本地Web應(yīng)用受保護資源的訪問請求，并且需要對請求方進行身份認證，重定向到CASServer進行認證。CAS協(xié)議基礎(chǔ)協(xié)議 上圖是一個基礎(chǔ)的CAS協(xié)議，CASClient以過濾器的方式保護Web應(yīng)用的受保護資源，過濾從客戶端過來的每一個Web請求，同時，CASClient會分析HTTP請求中是否包請求ServiceTicket(上圖中的Ticket)，如果沒有，則說明該用戶是沒有經(jīng)過認證的，CASClient會重定向用戶請求到CASServer（Step2）。Step3是用戶認證過程，如果用戶提供了正確的認證信息，CASServer會產(chǎn)生一個隨機的ServiceTicket，會向User發(fā)送一個Ticketgrantingcookie(TGC)給User的瀏覽器，并且重定向用戶到CASClient（附帶剛才產(chǎn)生的ServiceTicket），Step5和Step6是CASClient和CASServer之間完成了一個對用戶的身份核實，用Ticket查到Username，認證通過。在該協(xié)議中，所有與CAS的交互均采用SSL協(xié)議，確保，ST和TGC的安全性。協(xié)議工作過程中會有2次重定向的過程，但是CASClient與CASServer之間進行Ticket驗證的過程對于用戶是透明的。上圖是一個基礎(chǔ)的CAS協(xié)議，CASClient以過濾器的方式保護Web應(yīng)用的受保護資源，過濾從客戶端過來的每一個Web請求，同時，CASClient會分析HTTP請求中是否包請求ServiceTicket(上圖中的Ticket)，如果沒有，則說明該用戶是沒有經(jīng)過認證的，CASClient會重定向用戶請求到CASServer（Step2）。Step3是用戶認證過程，如果用戶提供了正確的認證信息，CASServer會產(chǎn)生一個隨機的ServiceTicket，會向User發(fā)送一個Ticketgrantingcookie(TGC)給User的瀏覽器，并且重定向用戶到CASClient（附帶剛才產(chǎn)生的ServiceTicket），Step5和Step6是CASClient和CASServer之間完成了一個對用戶的身份核實，用Ticket查到Username，認證通過。在該協(xié)議中，所有與CAS的交互均采用SSL協(xié)議，確保，ST和TGC的安全性。協(xié)議工作過程中會有2次重定向的過程，但是CASClient與CASServer之間進行Ticket驗證的過程對于用戶是透明的。方案三OAuth OAuth（OpenAuthorization，開放授權(quán)）是為用戶資源的授權(quán)定義了一個安全、開放及簡單的標(biāo)準(zhǔn)，第三方無需知道用戶的賬號及密碼，就可獲取到用戶的授權(quán)信息，并且這是安全的。 OAuth的原理（流程圖）我在圖上分了四個步驟，下面是四步的講解：第一步：用戶訪問第三方網(wǎng)站，比如：就是你需要使用QQ進行登錄的網(wǎng)站；第二步：你點擊QQ登錄后，第三方網(wǎng)站將會連接并進行請求，比如：你點擊登錄后，第三方網(wǎng)站會跳轉(zhuǎn)到QQ平臺，提示你進行登錄；第三步：你要進行授權(quán)第三方網(wǎng)站對你的信息訪問的一個權(quán)限，比如：當(dāng)你QQ登錄成功后，QQ會提示你，是否授權(quán)第三方Web訪問你的用戶基本信息或其他的資源信息，這時你點擊授權(quán)即可；第四步：授權(quán)后，第三方Web即可訪問你剛才授權(quán)的資源信息，比如：你的QQ基本信息-頭像、昵稱、性別等。通過這個原理圖示及講解，相信大家都了解了OAuth這個原理的一個基本流程。方案四SAML SAML即安全斷言標(biāo)記語言，英文全稱是SecurityAssertionMarkupLanguage。它是一個基于XML的標(biāo)準(zhǔn)，用于在不同的安全域(securitydomain)之間交換認證和授權(quán)數(shù)據(jù)。在SAML標(biāo)準(zhǔn)定義了身份提供者(identityprovider)和服務(wù)提供者(serviceprovider)，這兩者構(gòu)成了前面所說的不同的安全域。SAML是OASIS組織安全服務(wù)技術(shù)委員會(SecurityServicesTechnicalCommittee)的產(chǎn)品。SAML（SecurityAssertionMarkupLanguage）是一個XML框架，也就是一組協(xié)議，可以用來傳輸安全聲明。比如，兩臺遠程機器之間要通訊，為了保證安全，我們可以采用加密等措施，也可以采用SAML來傳輸，傳輸?shù)臄?shù)據(jù)以XML形式，符合SAML規(guī)范，這樣我們就可以不要求兩臺機器采用什么樣的系統(tǒng)，只要求能理解SAML規(guī)范即可，顯然比傳統(tǒng)的方式更好。SAML規(guī)范是一組Schema定義?？梢赃@么說，在WebService領(lǐng)域，schema就是規(guī)范，在Java領(lǐng)域，API就是規(guī)范。SAML作用SAML主要包括三個方面：1.認證申明。表明用戶是否已經(jīng)認證，通常用于單點登錄。2.屬性申明。表明某個Subject的屬性。3.授權(quán)申明。表明某個資源的權(quán)限。SAML框架SAML就是客戶向服務(wù)器發(fā)送SAML請求，然后服務(wù)器返回SAML響應(yīng)。數(shù)據(jù)的傳輸以符合SAML規(guī)范的XML格式表示。SAML可以建立在SOAP上傳輸，也可以建立在其他協(xié)議上傳輸。因為SAML的規(guī)范由幾個部分構(gòu)成：SAMLAssertion，SAMLPrototol，SAMLbinding等安全由于SAML在兩個擁有共享用戶的站點間建立了信任關(guān)系，所以安全性是需考慮的一個非常重要的因素。SAML中的安全弱點可能危及用戶在目標(biāo)站點的個人信息。SAML依靠一批制定完善的安全標(biāo)準(zhǔn)，包括SSL和X.509，來保護SAML源站點和目標(biāo)站點之間通信的安全。源站點和目標(biāo)站點之間的所有通信都經(jīng)過了加密。為確保參與SAML交互的雙方站點都能驗證對方的身份，還使用了證書。二、基于SAML的SSO下面簡單介紹使用基于SAML的SSO登錄到WebApp1的過程此圖片說明了以下步驟。用戶嘗試訪問WebApp1。WebApp1生成一個SAML身份驗證請求。SAML請求將進行編碼并嵌入到SSO服務(wù)的網(wǎng)址中。包含用戶嘗試訪問的WebApp1應(yīng)用程序的編碼網(wǎng)址的RelayState參數(shù)也會嵌入到SSO網(wǎng)址中。該RelayState參數(shù)作為不透明標(biāo)識符，將直接傳回該標(biāo)識符而不進行任何修改或檢查。WebApp1將重定向發(fā)送到用戶的瀏覽器。重定向網(wǎng)址包含應(yīng)向SSO服務(wù)提交的編碼SAML身份驗證請求。SSO（統(tǒng)一認證中心或叫IdentityProvider）解碼SAML請求，并提取WebApp1的ACS（聲明客戶服務(wù)）網(wǎng)址以及用戶的目標(biāo)網(wǎng)址（RelayState參數(shù)）。然后，統(tǒng)一認證中心對用戶進行身份驗證。統(tǒng)一認證中心可能會要求提供有效登錄憑據(jù)或檢查有效會話Cookie以驗證用戶身份。統(tǒng)一認證中心生成一個SAML響應(yīng)，其中包含經(jīng)過驗證的用戶的用戶名。按照SAML2.0規(guī)范，此響應(yīng)將使用統(tǒng)一認證中心的DSA/RSA公鑰和私鑰進行數(shù)字簽名。統(tǒng)一認證中心對SAML響應(yīng)和RelayState參數(shù)進行編碼