aspnet跨域sso解決方案(已修改)
2025-11-17 07:35 本頁面
【正文】 跨域 SSO的實現(xiàn)之一：架構(gòu)設(shè)計 翻譯自 CodeProject網(wǎng)站 ： Single Sign On (SSO) for crossdomain applications。 翻譯不妥之處還望大家多多指導、相互交流。 文章分為兩部分：架構(gòu)設(shè)計和程序?qū)崿F(xiàn)，此為第一篇即：架構(gòu)設(shè)計或者叫設(shè)計藍圖（ PartI The design blue print）。 :) 簡介 周一的早晨，當你正在納悶周末咋就一眨眼過去了并對接下來漫長的一周感到無比蛋疼之時，你收到了一份 Email。 操蛋的是它既不是微軟的 offer也不是 Google的 offer，而是客戶發(fā)來的一個新需求。 他說你們現(xiàn)在幫我們公司做了很多的 ，現(xiàn)在我想要我的客戶只要在我們擁有的任何一個網(wǎng)站上登錄一次，那么在我所有的網(wǎng)站上該用戶就都已經(jīng)登錄了，同樣，隨便他從哪個網(wǎng)站上注銷掉，那么他也就從我們所有的網(wǎng)站上注銷了 ...... 你受不了客戶這么羅嗦了，心想不就是要一個 SSO功能嗎？使用 form authentication不就可以實現(xiàn)了？因為這樣可以在同域的不用網(wǎng)站下共享 cookie，只需要在machineKey設(shè)置一樣的 配置節(jié)就可以了。放狗一搜，果然有 xxxx條結(jié)果。放狗找東西可是我們程序員的特長。 開工前，你又掃了一眼郵件，等等，你看到了郵件中的一行話，微微一蛋疼：我們部署了那些網(wǎng)站，但不是都在同一個域名下。 你的客戶狠狠地給你來了個下馬威，好像他早就放狗搜過，因為 cookie不能跨域共享，也就不能用來實現(xiàn)跨域驗證了。 這到底是神馬一回事情?。ê屠贤庖粯映锻娴旅嬲?jīng)些） 這個問題可能是老生常談了，但在解決難題之前，還是先回歸基礎(chǔ)來看一看事物的本質(zhì)到底是如何的。因此，我們重溫一下 。 下面是 驗證流程 1：你訪問一個需要用戶驗證的 2：在此請求中 cookie(由于表單驗證的 cookie)，如果沒有查找到，那么將跳轉(zhuǎn)到登錄頁面 (登錄頁地址配置在了 中 ) 3：在登錄頁面中，你提供了相關(guān)的驗證憑證并點擊了登錄按鈕，系統(tǒng)和已存儲的數(shù)據(jù)對比驗證成功后，將 的屬性值設(shè)置成了你提供的用戶名，并在 Response中寫入了 cookie(同時還寫入了用戶信息和一些如 cookie名，失效日期等 )，并重定向到登錄前的頁面。 4：當你再點擊其他的頁面 (或者點擊導航到其他的頁面 )，瀏覽器發(fā)送驗證的 cookie(也可能包含在該網(wǎng)站下寫入的一些其他 cookie)，這一次已經(jīng)包含了在上一次 response中上次 驗證獲取到的 cookie。 5：和以前一樣， cookie，這一次找到了，接下來做一些檢查 (如失效日期、路徑等等 )，如果還沒有失效，那么讀取出它的值，恢復出用戶的信息，將 的屬性值設(shè)置成恢復出的用戶名，檢查該用戶是否有權(quán)限去訪問當前請求的頁面，如果有，那么頁面執(zhí)行的結(jié)果返回到用戶的瀏覽器。 過程很簡單，對嗎？ 如前所述， cookie。那么只要使得不同的站點共享同樣的驗證 cookie，那么就可以實現(xiàn)在一個站點登錄實現(xiàn)所有站點的登錄。 HTTP協(xié)議指出，如果兩個站點是同域 (或者是子域 )的，那么可以共享 cookie。本地的處理是瀏覽器根據(jù)網(wǎng)
教學課件相關(guān)推薦
鄂ICP備17016276號-1