介紹
SSO英文全稱Single Sign On评姨，單點登錄。SSO是在多個應用系統(tǒng)中萤晴，用戶只需要登錄一次就可以訪問所有相互信任的應用系統(tǒng)吐句。它包括可以將這次主要的登錄映射到其他應用中用于同一個用戶的登錄的機制。它是目前比較流行的企業(yè)業(yè)務整合的解決方案之一店读。
實現(xiàn)機制
當用戶第一次訪問應用系統(tǒng)1的時候嗦枢，因為還沒有登錄，會被引導到認證系統(tǒng)中進行登錄屯断；根據(jù)用戶提供的登錄信息文虏，認證系統(tǒng)進行身份校驗，如果通過校驗殖演，應該返回給用戶一個認證的憑據(jù)－－ticket氧秘；用戶再訪問別的應用的時候就會將這個ticket帶上，作為自己認證的憑據(jù)趴久，應用系統(tǒng)接受到請求之后會把ticket送到認證系統(tǒng)進行校驗丸相，檢查ticket的合法性。如果通過校驗彼棍，用戶就可以在不用再次登錄的情況下訪問應用系統(tǒng)2和應用系統(tǒng)3了灭忠。
要實現(xiàn)SSO，需要以下主要的功能：
系統(tǒng)共享
統(tǒng)一的認證系統(tǒng)是SSO的前提之一滥酥。認證系統(tǒng)的主要功能是將用戶的登錄信息和用戶信息庫相比較更舞，對用戶進行登錄認證；認證成功后坎吻，認證系統(tǒng)應該生成統(tǒng)一的認證標志（ticket）缆蝉，返還給用戶。另外，認證系統(tǒng)還應該對ticket進行校驗刊头，判斷其有效性黍瞧。
信息識別
要實現(xiàn)SSO的功能，讓用戶只登錄一次原杂，就必須讓應用系統(tǒng)能夠識別已經(jīng)登錄過的用戶印颤。應用系統(tǒng)應該能對ticket進行識別和提取，通過與認證系統(tǒng)的通訊穿肄，能自動判斷當前用戶是否登錄過年局，從而完成單點登錄的功能。
另外：
1咸产、單一的用戶信息數(shù)據(jù)庫并不是必須的矢否，有許多系統(tǒng)不能將所有的用戶信息都集中存儲，應該允許用戶信息放置在不同的存儲中脑溢，事實上僵朗，只要統(tǒng)一認證系統(tǒng)，統(tǒng)一ticket的產(chǎn)生和校驗屑彻，無論用戶信息存儲在什么地方验庙，都能實現(xiàn)單點登錄。
2社牲、統(tǒng)一的認證系統(tǒng)并不是說只有單個的認證服務器
當用戶在訪問應用系統(tǒng)1時粪薛，由第一個認證服務器進行認證后，得到由此服務器產(chǎn)生的ticket膳沽。當他訪問應用系統(tǒng)2的時候汗菜，認證服務器2能夠識別此ticket是由第一個服務器產(chǎn)生的让禀，通過認證服務器之間標準的通訊協(xié)議（例如SAML）來交換認證信息挑社，仍然能夠完成SSO的功能。
WEB-SSO
用戶在訪問頁面1的時候進行了登錄巡揍，但是客戶端的每個請求都是單獨的連接痛阻，當客戶再次訪問頁面2的時候，如何才能告訴Web服務器腮敌，客戶剛才已經(jīng)登錄過了呢阱当？瀏覽器和服務器之間有約定：通過使用cookie技術(shù)來維護應用的狀態(tài)。Cookie是可以被Web服務器設(shè)置的字符串糜工，并且可以保存在瀏覽器中弊添。當瀏覽器訪問了頁面1時，web服務器設(shè)置了一個cookie捌木，并將這個cookie和頁面1一起返回給瀏覽器油坝，瀏覽器接到cookie之后，就會保存起來，在它訪問頁面2的時候會把這個cookie也帶上澈圈，Web服務器接到請求時也能讀出cookie的值彬檀，根據(jù)cookie值的內(nèi)容就可以判斷和恢復一些用戶的信息狀態(tài)。Web-SSO完全可以利用Cookie技術(shù)來完成用戶登錄信息的保存瞬女，將瀏覽器中的Cookie和上文中的Ticket結(jié)合起來窍帝，完成SSO的功能。
為了完成一個簡單的SSO的功能诽偷，需要兩個部分的合作：
1坤学、統(tǒng)一的身份認證服務。
2报慕、修改Web應用拥峦，使得每個應用都通過這個統(tǒng)一的認證服務來進行身份校驗。
CAS官網(wǎng)上的標準流程
具體流程如下：
用戶訪問app系統(tǒng)卖子，app系統(tǒng)是需要登錄的略号，但用戶現(xiàn)在沒有登錄。
跳轉(zhuǎn)到CAS server洋闽，即SSO登錄系統(tǒng)玄柠，以后圖中的CAS Server我們統(tǒng)一叫做SSO系統(tǒng)。 SSO系統(tǒng)也沒有登錄诫舅，彈出用戶登錄頁羽利。
用戶填寫用戶名、密碼刊懈，SSO系統(tǒng)進行認證后这弧，將登錄狀態(tài)寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie虚汛。
SSO系統(tǒng)登錄完成后會生成一個ST（Service Ticket）匾浪，然后跳轉(zhuǎn)到app系統(tǒng)，同時將ST作為參數(shù)傳遞給app系統(tǒng)卷哩。
app系統(tǒng)拿到ST后蛋辈，從后臺向SSO發(fā)送請求，驗證ST是否有效将谊。
驗證通過后冷溶，app系統(tǒng)將登錄狀態(tài)寫入session并設(shè)置app域下的Cookie。
至此尊浓，跨域單點登錄就完成了逞频。以后我們再訪問app系統(tǒng)時，app就是登錄的栋齿。接下來苗胀，我們再看看訪問app2系統(tǒng)時的流程托酸。用戶訪問app2系統(tǒng)，app2系統(tǒng)沒有登錄柒巫，跳轉(zhuǎn)到SSO励堡。
由于SSO已經(jīng)登錄了，不需要重新登錄認證堡掏。
SSO生成ST应结，瀏覽器跳轉(zhuǎn)到app2系統(tǒng)，并將ST作為參數(shù)傳遞給app2泉唁。
app2拿到ST鹅龄，后臺訪問SSO，驗證ST是否有效亭畜。
驗證成功后扮休，app2將登錄狀態(tài)寫入session，并在app2域下寫入Cookie拴鸵。
這樣玷坠，app2系統(tǒng)不需要走登錄流程，就已經(jīng)是登錄了劲藐。SSO八堡，app和app2在不同的域，它們之間的session不共享也是沒問題的聘芜。
問題：SSO系統(tǒng)登錄后兄渺，跳回原業(yè)務系統(tǒng)時，帶了個參數(shù)ST汰现，業(yè)務系統(tǒng)還要拿ST再次訪問SSO進行驗證挂谍，覺得這個步驟有點多余。他想SSO登錄認證通過后瞎饲，通過回調(diào)地址將用戶信息返回給原業(yè)務系統(tǒng)口叙，原業(yè)務系統(tǒng)直接設(shè)置登錄狀態(tài)，這樣流程簡單企软，也完成了登錄庐扫，不是很好嗎饭望？
其實這樣問題時很嚴重的仗哨，如果我在SSO沒有登錄，而是直接在瀏覽器中敲入回調(diào)的地址铅辞，并帶上偽造的用戶信息厌漂，是不是業(yè)務系統(tǒng)也認為登錄了呢？這是很可怕的斟珊。
單點登錄苇倡，資源都在各個業(yè)務系統(tǒng)這邊，不在SSO那一方。 用戶在給SSO服務器提供了用戶名密碼后旨椒，作為業(yè)務系統(tǒng)并不知道這件事晓褪。 SSO隨便給業(yè)務系統(tǒng)一個ST，那么業(yè)務系統(tǒng)是不能確定這個ST是用戶偽造的综慎，還是真的有效涣仿，所以要拿著這個ST去SSO服務器再問一下，這個用戶給我的ST是否有效示惊，是有效的我才能讓這個用戶訪問好港。
