什麼是SSO?
單一登入SSO(Single Sign-On)是身分識別管理的一部分。 SSO的一種較為通俗的定義是:SSO是指訪問同一伺服器不同應用中的受保護資源的同一用戶,只需要登入一次,即透過一個應用程式中的安全驗證後,再訪問其他應用程式中的受保護資源時,不再需要重新登入驗證
SSO的用途:
目前的企業應用環境中,往往有很多的應用系統,淘寶、天貓、愛淘寶等等產品和如辦公室自動化(OA)系統,財務管理系統,檔案管理系統,資訊查詢系統等等。這些應用系統服務企業的資訊化建設,為企業帶來了很好的效益。但是,使用者在使用這些應用系統時,並不方便。使用者每次使用系統,都必須輸入使用者名稱和使用者密碼,進行身份驗證;而且應用系統不同,使用者帳號就不同,使用者必須同時牢記多套使用者名稱和使用者密碼。特別是對於應用系統數目較多,使用者數目也很多的企業,這個問題特別突出。問題的原因並不是系統開發出現失誤,而是缺乏整體規劃,缺乏統一的使用者登入平台,使用SSO技術可以解決以上這些問題
SSO的好處:
方便使用者:從使用者實際使用角度來考慮
使用者使用應用系統時,能夠一次登錄,並多次使用。使用者不再需要每次輸入使用者名稱和使用者密碼,也不需要牢記多套使用者名稱和使用者密碼。單一登入平台能夠改善使用者使用應用系統的體驗。
方便管理員:從日常維護管理角度考慮
現在很多大的互聯網公司都會有很多的應用,比如以下是淘寶網的截圖:
天貓聚頭條等都是不同划算的應用,有的甚至採用完全不同的域名,但是所有在淘寶註冊的用戶都是使用的一套用戶名和口令,如果在這些系統直接切換做不到登陸狀態的同步,體驗是非常差的。再舉個栗子,很多公司內部系統也有很多個,比如HR系統,財務系統,考勤系統等等,如果員工在一個系統登陸了,跳轉到另外一個系統還需要登陸,就會讓人很不爽. ..
基於此,SSO(Single Sign On)應運而生。當然,我們來現實這個需求的方法有很多種,使用Cookie是其中比較簡單的方式,主要需要解決的問題是:Cookie是不能跨域傳遞的,如何將一個域的Cookie通知給其它應用(不在同一個域)?
so,如果你對cookie機制不太熟悉,請先google,大致了解為什麼cookie會設計成不能跨域等相關問題。
系統管理員只需要維護一套統一的使用者帳號,方便、簡單。相較之下,系統管理員以前需要管理很多套的使用者帳號。每一個應用系統就有一套使用者帳號,不僅為管理上帶來不方便,而且,也容易出現管理漏洞。
簡化應用系統開發:從應用擴充角度考慮
開發新的應用系統時,可直接使用單一登入平台的使用者認證服務,簡化開發流程。單一登入平台透過提供統一的認證平台,實現單一登入。因此,應用系統並不需要開發使用者認證程序。
如何實現?
SSO有以下幾種方式實現
共享Cookie
當我們的子系統都在一個父級域名下時,我們可以將Cookie種在父域下,這樣瀏覽器同域名下的Cookie則可以共享,這樣可以透過Cookie加解密的演算法來取得用戶SessionID,從而實現SSO。
但是,後面我們發現這種方式有幾種弊端:
a. 所有同域名的系統都能獲取SessionID,易被修改且不安全;
b. 跨域無法使用。
ticket驗證,我們目前採取的是這種方式
這種實現的SSO有以下幾個步驟:
a. 用戶訪問某個子系統,發現如果未登錄,則引導用戶跳轉到SSO登入頁面;
b. 判斷SSO是否已登入;
c. 如果已經登錄,直接跳到回呼地址,並返回認證ticket;
d. 如果未登錄,使用者正確輸入使用者名稱/密碼,認證透過跳前往回呼地址,並返回認證ticket;
e. 子系統獲取ticket,調用SSO獲取用戶uid等信息,成功後讓用戶登錄。
前面已經說了,如何透過Cookie來實現SSO,主要是如何解決跨域問題。首先來談談Set-Cookie中的domain屬性。
Cookie domain
為了讓Http協定在一定程度上保持上下文,server在回應的頭部可以加入Set-Cookie來寫入一些資料到客戶端,Set-Cookie中的
domain欄位用來表示這個cookie所在的網域。
栗子:
我們訪問www.cookieexm.com,如果server在返回頭部中加入了Set-Cookie,如果不指定domain,那麼默認這個cookie的域就是www.cookieexm.com,也就是只有訪問www .cookieexm.com時客戶端才會把這個cookie回給服務端。
如果我們指定domain為.cookieexm.com,那麼客戶端在造訪以下網域:www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com 時都能夠將cookie回傳。
所以,我們得出一條結論:客戶端對cookie的domain的匹配是從結尾進行匹配的,有了這個基礎,我們就可以實現我們的SSO登陸了。
cookie中需要注意的
設定為http-only
涉及登入憑證(如票據或使用者名稱)應該加密
cookie不能存放在子系統**.a1.a2 **.b1.b2 **.c1.c2間實現單一登錄,首先我們需要一個專門用於單點登陸的認證系統(sso.s1.s2)。假設目前系統處於未登入狀態,造訪www.a1.a2為例:
www.a1.a2收到請求,檢查是否攜帶登入的cookie,目前沒有登陸過,那麼重定向到sso認證中心
SSO提供登陸窗口,用戶輸入用戶名口令。 SSO系統驗證使用者名稱和口令這一步驟是關鍵,如果登入成功,首先把SSO系統的Cookie放到客戶端;同時,將使用者的認證資訊傳遞透過重定向傳遞給業務方,注意,這個傳遞明顯不能透過cookie來傳遞(不同域嘛),一般是透過加密的querystring。
業務方的驗證系統收到sso認證訊息,再進行認證
業務方認證通過之後,把認證結果的cookie寫入到.a1.a2,至此,SSO認證完成
重定向到業務系統www.a1 .a2,由前面的結論可知,此時所有以.a1.a2結尾的業務系統都可以使用這個認證之後的cookie
說明:
業務認證系統不一定存在,有些不是太敏感的系統可以直接從SSO Authorization重新導向到業務系統,並把SSO的認證資訊帶過去。
承接上文,此時,如果用戶訪問www.b1.b2應用,如下圖所示:
以上,就是一個簡單的基於Cookie的登陸系統。
其中幾個問題需要重點解決如何防止信息傳遞過程被篡改
如何讓SSO系統信任登錄系統和免登系統對於第一個問題,一般可以採用類似與memcached的分散式快取的方案,既能提供可擴展資料量的機制,也能提供高效存取
對於最後一個問題,可以透過白名單來處理,說簡單點只有在白名單上的系統才能請求生產信任關係,同理只有白名單上的系統才能被免登入。
更多PHP中SSO Cookie登入分析與實現相關文章請關注PHP中文網!