用戶(hù)驗證流程

　　用戶(hù)未登陸時(shí)的驗證流程

　　用戶(hù)未在ZAS Server上登陸之前訪(fǎng)問(wèn)ZAS Client的被保護資源時(shí)，根據信任模式的不同，有一般模式下的流程和信任模式下的流程兩種驗證流程。

　　一般模式下的驗證流程：

　　如上圖所示，一般模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)A的被保護資源。

　　第二步：服務(wù)A發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令。

　　第三步：瀏覽器重定向到ZAS Server,顯示輸入驗證信息的頁(yè)面。

　　第四步：用戶(hù)輸入驗證信息后，ZAS Server判斷驗證信息是否正確，如果不正確，流程中止。如果正確，則指示瀏覽器重定向到服務(wù)A，并將ST作為URL參數附加到服務(wù)A的URL上，同時(shí)將TGC傳給瀏覽器，瀏覽器儲存TGC。

　　第五步：服務(wù)A獲得ST，但服務(wù)A不知道該ST是否是偽造的，因此服務(wù)A將ST傳給ZAS Server,判斷ST是否正確。

　　第六步：ZAS Server獲得服務(wù)Ａ傳過(guò)來(lái)的ST,因為所有的ST都是由ZAS Server產(chǎn)生的，因此ZAS Server很容易判斷ST是否正確。如果ST不正確，流程中止。如果正確，則返回用戶(hù)名給服務(wù)A。

　　第七步：服務(wù)A確認該用戶(hù)已經(jīng)登陸，并得到了用戶(hù)名，因此可以為該用戶(hù)產(chǎn)生Session并繼續提供服務(wù)，流程結束。

　　信任模式下的驗證流程：

　　如上圖所示，信任模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)A的被保護資源。

　　第二步：服務(wù)A發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令。

　　第三步：瀏覽器重定向到ZAS Server，顯示輸入驗證信息的頁(yè)面。

　　第四步：用戶(hù)輸入驗證信息后，ZAS Server判斷驗證信息是否正確，如果不正確，流程中止。如果正確，則指示瀏覽器重定向到服務(wù)A，并用服務(wù)A的密鑰加密后的用戶(hù)名作為URL參數附加到服務(wù)A的URL上，同時(shí)將TGC傳給瀏覽器，瀏覽器儲存TGC。

　　第五步：服務(wù)A接收到加密后的用戶(hù)名，如果不能用自己的密鑰解密，則說(shuō)明傳輸過(guò)程中出現了異常（一般是被非法篡改），流程中止。如果能正確解密，則可以為該用戶(hù)產(chǎn)生Session并繼續提供服務(wù)，流程結束。

　　用戶(hù)己登陸時(shí)的驗證流程

　　用戶(hù)己在ZAS Server上登陸并使用過(guò)服務(wù)A，但未使用過(guò)服務(wù)B，則訪(fǎng)問(wèn)服務(wù)B的被保護資源時(shí)會(huì )要求驗證TGC(但不需要用戶(hù)再次輸入驗證信息)。根據信任模式的不同，有一般模式下的流程和信任模式下的流程兩種驗證流程。

　　一般模式下的驗證流程：

　　如上圖所示，一般模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)B的被保護資源。

　　第二步：服務(wù)B發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令，因為用戶(hù)已經(jīng)登陸過(guò)，所以瀏覽器會(huì )在Http請求中附帶上TGC給ZAS Server。

　　第三步：ZAS Server獲取TGC后判斷TGC中的TGT標識符是否正確，如果不正確，流程中止。如果正確，則指示瀏覽器重定向到服務(wù)A，并將生成的ST作為URL參數附加到服務(wù)B的URL上。

　　第五步：服務(wù)B獲得ST，但服務(wù)B不知道該ST是否是偽造的，因此服務(wù)B將ST傳給ZAS Server,判斷ST是否正確。

　　第六步：ZAS Server獲得服務(wù)B傳過(guò)來(lái)的ST,因為所有的ST都是由ZAS Server產(chǎn)生的，因此ZAS Server很容易判斷ST是否正確。如果ST不正確，流程中止。如果正確，則返回用戶(hù)名給服務(wù)A。

　　第七步：服務(wù)B確認該用戶(hù)已經(jīng)登陸，并得到了用戶(hù)名，因此可以為該用戶(hù)產(chǎn)生Session并繼續提供服務(wù)，流程結束。

　　信任模式下的驗證流程：

　　如上圖所示，信任模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)B的被保護資源。

　　第二步：服務(wù)B發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令，因為用戶(hù)已經(jīng)登陸過(guò)，所以瀏覽器會(huì )在Http請求中附帶上TGC給ZAS Server。。

　　第三步：瀏覽器重定向到ZAS Server，ZAS Server檢查T(mén)GC中的TGT標識符是否正確，如果不正確，流程中止，如果正確，則指示瀏覽器重定向到服務(wù)B，并用服務(wù)B的密鑰加密后的用戶(hù)名作為URL參數附加到服務(wù)B的URL上。

　　第五步：服務(wù)B接收到加密后的用戶(hù)名，如果不能用自己的密鑰解密，則說(shuō)明傳輸過(guò)程中出現了異常（一般是被非法篡改），流程中止。如果能正確解密，則可以為該用戶(hù)產(chǎn)生Session并繼續提供服務(wù)，流程結束。

　　代理訪(fǎng)問(wèn)時(shí)的驗證流程

　　假設這樣一種場(chǎng)景：用戶(hù)訪(fǎng)問(wèn)服務(wù)A（不妨假設服務(wù)A是Portal），服務(wù)A又依賴(lài)于服務(wù)B來(lái)獲取一些信息，而服務(wù)B也是需要對用戶(hù)進(jìn)行身份驗證才能訪(fǎng)問(wèn)，如果按照2.2或2.3節中的驗證流程，則瀏覽器必須在A(yíng)、B、ZAS Server之間多次重定向。為了避免過(guò)多的重定向影響用戶(hù)體驗，ZAS 引入了Proxy 驗證機制，即 ZAS Client 可以代理用戶(hù)去訪(fǎng)問(wèn)其它 ZAS Client 。

　　一般模式下的驗證流程：

　　如上圖所示，一般模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)A的被保護資源，服務(wù)Ａ需要代理用戶(hù)訪(fǎng)問(wèn)其他服務(wù)。

　　第二步：服務(wù)A發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令。

　　第三步：瀏覽器重定向到ZAS Server,顯示輸入驗證信息的頁(yè)面。

　　第四步：用戶(hù)輸入驗證信息后，ZAS Server判斷驗證信息是否正確，如果不正確，流程中止。如果正確，則指示瀏覽器重定向到服務(wù)A，并將ST作為URL參數附加到服務(wù)A的URL上，同時(shí)將TGC傳給瀏覽器，瀏覽器儲存TGC。

　　第五步：服務(wù)A獲得ST，但服務(wù)A不知道該ST是否是偽造的，因此服務(wù)A將ST傳給ZAS Server，判斷ST是否正確。

　　第六步：ZAS Server獲得服務(wù)Ａ傳過(guò)來(lái)的ST,因為所有的ST都是由ZAS Server產(chǎn)生的，因此ZAS Server很容易判斷ST是否正確。如果ST不正確，流程中止。如果正確，則反向調用服務(wù)Ａ的ProxyCallbackURL將PGT和用戶(hù)名傳遞給服務(wù)Ａ。

　　第七步：返回用戶(hù)名給服務(wù)A。

　　第八步：服務(wù)A確認該用戶(hù)已經(jīng)登陸，并得到了用戶(hù)名，因此可以為該用戶(hù)產(chǎn)生Session，然后準備提供服務(wù)給用戶(hù)，但又發(fā)現需要服務(wù)Ｂ提供的數據才能進(jìn)行，因此服務(wù)Ａ發(fā)送PGT給ZAS Server以請求PT。

　　第九步：ZAS Server檢查PGT，如果PGT不正確，則流程中止，如果正確，則生成PT，返回給服務(wù)Ａ。

　　第十步：服務(wù)Ａ發(fā)送獲得的PT給服務(wù)Ｂ，請求代理。

　　第十一步：服務(wù)Ｂ不知道PT是否是偽造的，因此服務(wù)Ｂ將PT發(fā)送給ZAS Server驗證。

　　第十二步：因此一般模式下的所有PT都是由ZAS Server生成的，所以ZAS Server很容易就能夠判斷PT是否正確，如果不正確，則流程中止，如果正確，則返回PT對應的用戶(hù)名給服務(wù)Ｂ。

　　第十三步：服務(wù)Ｂ確認代理有效，并得到了用戶(hù)名，因此服務(wù)Ｂ可以為服務(wù)A提供數據。

　　第十四步：服務(wù)Ａ接收到服務(wù)Ｂ的數據，完成服務(wù)的準備工作，將結果顯示在用戶(hù)的瀏覽器上，流程結束。

　　注意：如果用戶(hù)已經(jīng)登陸，則代理訪(fǎng)問(wèn)時(shí)從第八步開(kāi)始。

　　信任模式下的驗證流程：

　　如上圖所示，信任模式下的驗證流程如下：

　　第一步：用戶(hù)訪(fǎng)問(wèn)服務(wù)A的被保護資源，服務(wù)Ａ需要代理用戶(hù)訪(fǎng)問(wèn)其他服務(wù)。

　　第二步：服務(wù)A發(fā)現沒(méi)有該用戶(hù)的Session，給瀏覽器發(fā)送重定向指令。

　　第三步：瀏覽器重定向到ZAS Server，顯示輸入驗證信息的頁(yè)面。

　　第四步：用戶(hù)輸入驗證信息后，ZAS Server判斷驗證信息是否正確，如果不正確，流程中止。如果正確，則指示瀏覽器重定向到服務(wù)A，并用服務(wù)A的密鑰加密后的用戶(hù)名作為URL參數附加到服務(wù)A的URL上，同時(shí)將TGC傳給瀏覽器，瀏覽器儲存TGC。

　　第五步：服務(wù)A接收到加密后的用戶(hù)名，如果不能用自己的密鑰解密，則說(shuō)明傳輸過(guò)程中出現了異常（一般是被非法篡改），流程中止。如果能正確解密，則可以為該用戶(hù)產(chǎn)生Session，然后準備提供服務(wù)給用戶(hù)，但又發(fā)現需要服務(wù)Ｂ提供的數據才能進(jìn)行，因此服務(wù)Ａ用自己的密鑰一個(gè)指定格式的加密PT并傳遞給服務(wù)Ｂ。

　　第六步：服務(wù)Ｂ不知道PT是否是偽造的，因此服務(wù)Ｂ將此PT轉發(fā)給ZAS Server請求驗證。

　　第七步：ZAS接收到PT，如果PT不能用服務(wù)A的密鑰解密，則流程中止，如果能夠正確解密，則返回PT對應的用戶(hù)名給服務(wù)Ｂ。

　　第八步：服務(wù)Ｂ確認代理有效，并得到了用戶(hù)名，因此服務(wù)Ｂ可以為服務(wù)A提供數據。

　　第九步：服務(wù)Ａ接收到服務(wù)Ｂ的數據，完成服務(wù)的準備工作，將結果顯示在用戶(hù)的瀏覽器上，流程結束。

　　注意：如果用戶(hù)已經(jīng)登陸，則代理訪(fǎng)問(wèn)時(shí)從第五步開(kāi)始。