PHP中SSO Cookie登入分析和實現

2022-10-05 03:15:10 字數 3683 閱讀 6229

什麼是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

www.a1.a2收到請求,檢查是否攜帶登入的cookie,目前沒有登陸過,那麼重定向到sso認證中心

sso提供登陸視窗,使用者輸入使用者名稱 口令。sso系統驗證使用者名稱和口令

這一步是關鍵,如果登入成功,首先把sso系統的cookie放到客戶端;同時,將使用者的認證資訊傳遞通過重定向傳遞給業務方,注意,這個傳遞明顯不能通過cookie來傳遞(不同域嘛),一般是通過加密的plrbwgruqquerystring。

業務方的驗證系統收到sso認證資訊,再進行認證

業務方認證通過之後,把認證結果的cookie寫入到.a1.a2,至此,sso程式設計客棧認證完成

重定向到業務系統www.a1.a2,由前面的結論可知,此時所有以.a1.a2結尾的業務系統都可以使用這個認證之後的cookie

response

說明:業務認證系統不一定存在,有些不是太敏感的系統可以直接從sso authorization重定向到業務系統,並把sso的認證資訊帶過去。

承接上文,此時,如果使用者訪問www.b1.b2應用,如下圖所示:

與訪問www.a1.a2不同的是我們在重定向到sso authorization時已經不需要再去輸入使用者名稱,因為sso.s1.s2此時已經存有cookie,直接用cookie驗證。

以上,就是乙個簡單的基於cookie的登陸系統。

其中幾個問題需要重點解決

如何高效儲存大量臨時性的信任資料

如何防止資訊傳遞過程被篡改

如何讓sso系統信任登入系統和免登系統

對於第乙個問題,一般可以採用類似與memcached的分布式快取的方案,既能提供可擴充套件資料量的機制,也能提供高效訪問

對於第二個問題,一般採取數字簽名的方法,要麼通過數字證書簽名,要麼通過像md5的方式,這就需要sso系統返回免登url的時候對需驗證的引數進行 md5加密,並帶上token一起返回,最後需免登的系統進行驗證信任關係的時候,需把這個token傳給sso系統,sso系統通過對token的驗證 就可以辨別資訊是否被改過

對於最後乙個問題,可以通過白名單來處理,說簡單點只有在白名單上的系統才能請求生產信任關係,同理只有在白名單上的系統才能被免登入。

本文標題: php中sso cookie登入分析和實現

本文位址: /wangluo/php/134488.html

php加密登入 PHP安全登入 密碼加密

以下是要實施安全登入的登入系統 main login.php username password checklogin.php ob start host localhost host name username root mysql username password mysql password...

PHP中的會話控制 單點登入

1 簡單使用下session 在使用session之前需要session start 開啟session 寫乙個demo來實現下 新建乙個session.php session start 使用時必須開啟,如果你在php.ini裡頭修改了配置那麼就無需在開啟session了 session user...

PHP中curl登入免cookie檔案儲存抓取網頁

問題的出現 用curl抓取需要登入的網頁資料時,首先要把登入後獲取的cookie通過檔案儲存下來 curl setopt ch,curlopt cookiejar,cookie 設定cookie資訊儲存在指定的檔案中 但檔案儲存的效率並不高,而且把它放在 的目錄下也要給予一定的許可權,會造成 的不安...