分享到：

電商平臺(tái)中無(wú)論是前端還是后端會(huì)存在大量的業(yè)務(wù)應(yīng)用，在整個(gè)交易的過(guò)程中請(qǐng)求是在各個(gè)業(yè)務(wù)應(yīng)用中流轉(zhuǎn)的，對(duì)于用戶來(lái)講只需要登錄一次就可以訪問所有的業(yè)務(wù)，這就是單點(diǎn)登錄SSO。

單點(diǎn)登錄開源有很多的解決方案，比如基于session的SSO和基于cookie的SSO。

業(yè)界使用比較多的基于session的SSO的開源解決方案比如CAS，流程示意圖如下：

這里不去詳細(xì)說(shuō)明流程，讀者可以參考其他資料的說(shuō)明

基于cookie的SSO在原理上和上面的差不多，區(qū)別是把用戶設(shè)置到cookie中作為token的一部分進(jìn)行傳遞，而基于session的SSO中cookie是服務(wù)器給客戶端生成的TGT。

相對(duì)來(lái)說(shuō)，基于cookie的安全性不高。

以上是單機(jī)環(huán)境下的方案，更多的滿足傳統(tǒng)企業(yè)級(jí)的方案；而在電商平臺(tái)中，對(duì)SSO的性能、可用性、緩存數(shù)據(jù)量都是一個(gè)挑戰(zhàn)，因此需要基于CAS做改造，滿足互聯(lián)網(wǎng)的要求。

簡(jiǎn)單對(duì)CAS的性能做了個(gè)壓測(cè)：

軟硬件環(huán)境：兩個(gè)App，一個(gè)CAS Server。機(jī)器都是PC server，16core 32G

場(chǎng)景：用戶在一個(gè)迭代中做登陸、操作業(yè)務(wù)、登出操作

測(cè)試結(jié)果：

CAS Server的機(jī)器情況
top - 17:05:18 up 1 day,  8:39,  2 users, load average: 4.25, 2.62, 1.22

Tasks: 783 total,   1 running, 782sleeping,   0 stopped,   0 zombie

Cpu(s): 69.4%us,  5.9%sy, 0.0%ni, 22.7%id,  0.0%wa,  0.0%hi,  2.0%si,  0.0%st

Mem:  65964644k total, 16462164k used,49502480k free,   251036k buffers

Swap: 30719992k total,       0k used, 30719992k free,  1240744k cached 

 

TPS：2000，RT：20-30ms

 

改造后的SSO的架構(gòu)示意圖如下：

1、  改造CAS Server為無(wú)狀態(tài)的節(jié)點(diǎn)，以前緩存的ticket、用戶等信息放到后端的cache中

2、  后端Cache采用redis,去掉持久化的功能，只做cache用

3、  考慮數(shù)據(jù)量的關(guān)系，Cache采用分布式的方案，進(jìn)行數(shù)據(jù)切分，每個(gè)sharding只存儲(chǔ)一定范圍的數(shù)據(jù)

4、  每個(gè)sharding采用主備方式，leader作為主節(jié)點(diǎn)，replica只作為備份，在主節(jié)點(diǎn)宕機(jī)時(shí)可以升級(jí)為主節(jié)點(diǎn)

5、  整個(gè)集群的采用zookeeper進(jìn)行分布式集群管理服務(wù)。

6、  App watch sso節(jié)點(diǎn)的變化，采用輪詢RR算法選擇一臺(tái)SSO Server進(jìn)行請(qǐng)求，SSOServer對(duì)ticket采用hash算法定位到后端的cache進(jìn)行存儲(chǔ)。

7、  用戶登出平臺(tái)時(shí)，采用輪詢RR算法選擇一臺(tái)SSO Server進(jìn)行請(qǐng)求，清除Cache中的相關(guān)信息以及http方式回調(diào)各個(gè)應(yīng)用的登出服務(wù)接口

8、平臺(tái)初始化階段需要把cache的各個(gè)sharding分配到某臺(tái)SSO Server上做定時(shí)的Ticketexpire驗(yàn)證清理工作，也就是一臺(tái)SSO Server負(fù)責(zé)一個(gè)或者多個(gè)sharding的Ticketexpire工作，進(jìn)而http方式回調(diào)各個(gè)應(yīng)用的登出服務(wù)接口。

電商平臺(tái)中無(wú)論是前端還是后端會(huì)存在大量的業(yè)務(wù)應(yīng)用，在整個(gè)交易的過(guò)程中請(qǐng)求是在各個(gè)業(yè)務(wù)應(yīng)用中流轉(zhuǎn)的，對(duì)于用戶來(lái)講只需要登錄一次就可以訪問所有的業(yè)務(wù)，這就是單點(diǎn)登錄SSO. 單點(diǎn)登錄開源有很多的解決方案，比如基于session的SSO和基于cookie的SSO. 業(yè)界使用比較多的基于session的SSO的開源解決方案比如CAS，流程示意圖如下：. 這里不去詳細(xì)說(shuō)明流程，讀者可以參考其他資料的說(shuō)明. 基于cookie的SSO在原理上和上面的差不多，區(qū)別是把用戶設(shè)置到cookie中作為token的一部分進(jìn)行傳遞，而基于session的SSO中cookie是服務(wù)器給客戶端生成的TGT. 相對(duì)來(lái)說(shuō)，基于cookie的安全性不高.

關(guān)于CAS很多的原理和基礎(chǔ)的配置啟動(dòng)，網(wǎng)上是很多的，我更多是結(jié)合我的實(shí)踐和心得. 需要了解CAS的原理，認(rèn)證協(xié)議，認(rèn)證流程，可以參考以下文章. 讓CAS支持客戶端自定義登陸頁(yè)面——客戶端篇. CAS原理與配置-基于CAS的單點(diǎn)登陸的研究（上）. 單點(diǎn)登錄(SSO)是企業(yè)開發(fā)的重要問題，在我的畢設(shè)項(xiàng)目中，由于要和系統(tǒng)其他開發(fā)模塊共用用戶認(rèn)證模塊，方便共享用戶資源，所以需要一個(gè)好的SSO解決方案. 一般SSO的實(shí)現(xiàn)機(jī)制有兩種：基于session的和基于cookie的. WebLogic通過(guò)Session共享認(rèn)證信息. Session是一種服務(wù)器端機(jī)制，當(dāng)客戶端訪問服務(wù)器時(shí)，服務(wù)器為客戶端創(chuàng)建一個(gè)惟一的SessionID，以使在整個(gè)交互過(guò)程中始終保持狀態(tài)，而交互的信息則可由應(yīng)用自行指定，因此用Session方式實(shí)現(xiàn)SSO，不能在多個(gè)瀏覽器之間實(shí)現(xiàn)單點(diǎn)登錄，但卻可以跨域；WebSphere通過(guò)Cookie記錄認(rèn)證信息.

SSO在我們的應(yīng)用中非常常見，例如我們?cè)贠A系統(tǒng)登錄了，我們就可以直接進(jìn)入采購(gòu)系統(tǒng)，不需要再登錄了，這樣使我們非常方便. 現(xiàn)在網(wǎng)上也有很多實(shí)現(xiàn)方法，于是乎我也想寫一個(gè)看看. 我主要用到的是cookie的機(jī)制. 在此，分享給大家， 同時(shí)提供源代碼下載. SSO的實(shí)現(xiàn)一般是會(huì)有一個(gè)SSO Server，也會(huì)叫認(rèn)證中心，同時(shí)也會(huì)有被認(rèn)證的系統(tǒng)，如OA系統(tǒng)、采購(gòu)系統(tǒng)等，他們就相當(dāng)于SSO Server的client. 為了更形象體現(xiàn)SSO，我寫的SSO是有三個(gè)工程：一個(gè)SSO Server端口為8081，一個(gè)OA系統(tǒng)端口為8082，一個(gè)采購(gòu)系統(tǒng)端口為8083. 在整個(gè)SSO流程當(dāng)，有兩個(gè)流程非常重要，第一個(gè)是用戶沒有登錄系統(tǒng)到登錄系統(tǒng)的過(guò)程；第二是用戶在一個(gè)系統(tǒng)當(dāng)中已經(jīng)登錄（例如在OA系統(tǒng)中登錄 了），但又想進(jìn)入另一個(gè)系統(tǒng)（例如進(jìn)入PRO系統(tǒng)）的過(guò)程，如果把這兩個(gè)過(guò)程搞定了，那么SSO也就搞定了.

自從CAS 3.4就很好的支持了單點(diǎn)注銷功能，配置也很簡(jiǎn)單. 之前版本因?yàn)樵贑AS服務(wù)器通過(guò)HttpClient發(fā)送消息時(shí)并未指定為POST方式，所以在CAS客戶端的注銷Filter中沒有收到POST請(qǐng)求（要知道Filter只對(duì)Post請(qǐng)求起作用），也就沒有做session銷毀處理. 兩個(gè)業(yè)務(wù)系統(tǒng)APP1和APP2. 在沒有配置單點(diǎn)退出時(shí)，效果是這樣子的. 1：登錄APP1，然后經(jīng)過(guò)CAS認(rèn)證后進(jìn)入APP1，再訪問APP2無(wú)需要認(rèn)證. 2：在APP1中連接到cas的logout地址，現(xiàn)象注銷成功界面，然后再訪問APP1，還是可以進(jìn)去的，因?yàn)锳PP1將用戶的登錄票據(jù)存入了session. 那么實(shí)現(xiàn)了單點(diǎn)退出后的效果應(yīng)該是這樣子的：.

整體的結(jié)構(gòu)就是cas+shiro實(shí)現(xiàn)單點(diǎn)登錄和權(quán)限管理. 怎么安裝就不說(shuō)了網(wǎng)上一大堆，在這總結(jié)一些問題的處理方法. 未能夠識(shí)別目標(biāo)'ST-2-jEo1qANhs9HgZ7VKC5Hf-cas'票根. 原因：是由于客戶端應(yīng)用web.xml配置中的casServerLoginUrl和casServerUrlPrefix兩個(gè)URL屬性的域名與證書中定義的不一致，或者你的地址配置的不對(duì)，配置serverUrl就到cas配置serviceUrl就到端口號(hào). 解決方案為查看service與loginUrl中的是否一致，這是兩個(gè)概念，service是請(qǐng)求的頁(yè)面，當(dāng)用戶訪問這個(gè)頁(yè)面是會(huì)跳轉(zhuǎn)至公共的驗(yàn)證平臺(tái)，而loginUrl中的service是回調(diào)的地址，如果兩個(gè)地址設(shè)定為同一地址的話就會(huì)出現(xiàn)循環(huán)重定向的問題.

單點(diǎn)登錄（Single Sign On, SSO）是企業(yè)應(yīng)用集成中最常見的需求. 異構(gòu)系統(tǒng)間往往都有各自的用戶管理和身份驗(yàn)證機(jī)制，為. 避免用戶在進(jìn)行系統(tǒng)切換時(shí)頻繁輸入用戶名和密碼，因此必須要實(shí)現(xiàn)單點(diǎn)登錄. 說(shuō)到SSO的原理，先得說(shuō)一般Web應(yīng)用的身份驗(yàn)證原理. Web身份驗(yàn)證之所以能成為問題主要在于HTTP協(xié)議的無(wú)狀態(tài)性，這導(dǎo). 致了每次HTTP的請(qǐng)求和響應(yīng)的無(wú)關(guān)性. 而應(yīng)用的狀態(tài)保持是大部分應(yīng)用系統(tǒng)的一般性需求，因此必須借助其他機(jī)制，這就是Cookie. 一個(gè)Cookie由name、value、domain、path、expires組成. 可以給HTTP響應(yīng)添加Cookie，然后Cookie就作為HTTP響應(yīng)的.

隨著互聯(lián)網(wǎng)絡(luò)應(yīng)用的普及，越來(lái)越多的人開始使用互聯(lián)網(wǎng)上提供的服務(wù). 然而目前提供服務(wù)的網(wǎng)站大多采用用戶名、口令的方式來(lái)識(shí)別用戶身份，這使得用戶需要經(jīng)常性的輸入自己的用戶名、口令. 顯然這種認(rèn)證方式存在著弊端：隨著用戶網(wǎng)絡(luò)身份的增多，用戶相應(yīng)的需要記憶多組用戶名、口令，這給用戶造成記憶上的負(fù)擔(dān)；另外頻繁的輸入用戶名、口令，會(huì)相應(yīng)的增大用戶的口令密碼被破解的機(jī)率. 為了改變這一現(xiàn)狀，單點(diǎn)登錄技術(shù)應(yīng)運(yùn)而生. 單點(diǎn)登錄技術(shù)的核心思想是通過(guò)一定的方式使得各提供服務(wù)的網(wǎng)站之間建立某種聯(lián)系，用戶只需要在其中一個(gè)認(rèn)證網(wǎng)站進(jìn)行登錄后，即可實(shí)現(xiàn)全局登錄，當(dāng)用戶再訪問其他網(wǎng)站時(shí)，不需要再次登錄，其身份就可以被驗(yàn)證. 我們可以看到采用單點(diǎn)登錄技術(shù)后，用戶只需要記憶一組用戶名、口令，并且在登錄多個(gè)網(wǎng)站時(shí)只需要輸入一次用戶名、口令，這就使得用戶可以更加安全快捷的使用互聯(lián)網(wǎng)上的各種服務(wù).

近日有道詞典Mac Beta版上線，為廣大使用 Mac的果粉們帶來(lái)了福音. 作為Mac系統(tǒng)中首家互聯(lián)網(wǎng)詞典，有道詞典Mac版在豐富的基本釋義基礎(chǔ)上，依 托網(wǎng)絡(luò)釋義功能，輕松囊括互聯(lián)網(wǎng)上最新最酷最流行的中外文詞匯. 同時(shí)有道詞典Mac版支持Safari、Chrome、Firefox等主流瀏覽器的取 詞、劃詞翻譯，讓用戶在使用翻譯服務(wù)時(shí)更加方便快捷. 此前Mac上的詞典軟件種類較少，僅有幾款詞典軟件的釋義均基于本地詞庫(kù). 在飛速發(fā)展的互聯(lián)網(wǎng)時(shí)代，每天產(chǎn)生著數(shù)量龐大的新鮮內(nèi)容，更新緩慢的本地靜態(tài)詞庫(kù)顯然已經(jīng)不能跟上時(shí)代的腳步. 有道詞典的網(wǎng)絡(luò)釋義功能，通過(guò)有道獨(dú)創(chuàng)的網(wǎng)頁(yè)萃取技術(shù)，對(duì)海量的中英文網(wǎng)頁(yè)進(jìn)行分析，以獲得最佳的翻譯結(jié)果.

幾周前，OpenSSL網(wǎng)站加密工具曝出的“Heartbleed”漏洞，已經(jīng)將整個(gè)互聯(lián)網(wǎng)安全領(lǐng)域震翻了一回. 盡管絕大多數(shù)網(wǎng)站都在第一時(shí)間修復(fù)了它，但是一個(gè)新的問題又浮出了水面. 一名安全研究人員發(fā)現(xiàn)了兩款登錄系統(tǒng)上的重大漏洞，而想要修復(fù)它們，卻比Heartbleed要困難得多. 據(jù)Cnet報(bào)道，新加坡南洋理工大學(xué)一位名叫Wang Jing的博士生，發(fā)現(xiàn)了OAuth和OpenID開源登錄工具的“隱蔽重定向”漏洞(Covert Redirect). 這可導(dǎo)致攻擊者創(chuàng)建一個(gè)使用真實(shí)站點(diǎn)地址的彈出式登錄窗口——而不是使用一個(gè)假的域名——以引誘上網(wǎng)者輸入他們的個(gè)人信息. 鑒于OAuth和OpenID被廣泛用于各大公司——如微軟、Facebook、Google、以及LinkedIn——Wang表示他已經(jīng)向這些公司已經(jīng)了匯報(bào).

作為一名普通微博用戶，在手機(jī)上使用 新浪微博客戶端，已經(jīng)輸入過(guò)自己的賬號(hào)及密碼，是否期待手機(jī)上的第三方應(yīng)用如360安全瀏覽器、唱吧等，可以識(shí)別當(dāng)前的微博賬號(hào)，而不需要重新輸入賬號(hào)密碼進(jìn)行登陸. 近日，新浪微博開放平臺(tái) SSO授權(quán)的正式上線，幫助用戶實(shí)現(xiàn)了這一愿望. SSO英文全稱Single Sign On(單點(diǎn)登錄)，意指用戶只需登錄一次，就可以訪問相互信任的其他應(yīng)用系統(tǒng). 新浪 微博開放平臺(tái)SSO授權(quán)的上線，意味著已經(jīng)安裝新浪微博客戶端的手機(jī)用戶，登陸經(jīng)此授權(quán)的第三方應(yīng)用時(shí)，只需要簡(jiǎn)單操作即可完成授權(quán)，之后就能使用新浪微博賬號(hào)和密碼登陸這些應(yīng)用，而不用重新輸入賬號(hào)和密碼. 若用戶手機(jī)中沒有安裝 微博客戶端，則會(huì)啟用網(wǎng)頁(yè)授權(quán)方式完成授權(quán).