用戶驗證流程

　　用戶未登陸時的驗證流程

　　用戶未在ZAS Server上登陸之前訪問ZAS Client的被保護資源時，根據信任模式的不同，有一般模式下的流程和信任模式下的流程兩種驗證流程。

　　一般模式下的驗證流程：

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

　　第一步：用戶訪問服務A的被保護資源。

　　第二步：服務A發現沒有該用戶的Session，給瀏覽器發送重定向指令。

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

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

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

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

　　第七步：服務A確認該用戶已經登陸，并得到了用戶名，因此可以為該用戶產生Session并繼續提供服務，流程結束。

　　信任模式下的驗證流程：

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

　　第一步：用戶訪問服務A的被保護資源。

　　第二步：服務A發現沒有該用戶的Session，給瀏覽器發送重定向指令。

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

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

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

　　用戶己登陸時的驗證流程

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

　　一般模式下的驗證流程：

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

　　第一步：用戶訪問服務B的被保護資源。

　　第二步：服務B發現沒有該用戶的Session，給瀏覽器發送重定向指令，因為用戶已經登陸過，所以瀏覽器會在Http請求中附帶上TGC給ZAS Server。

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

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

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

　　第七步：服務B確認該用戶已經登陸，并得到了用戶名，因此可以為該用戶產生Session并繼續提供服務，流程結束。

　　信任模式下的驗證流程：

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

　　第一步：用戶訪問服務B的被保護資源。

　　第二步：服務B發現沒有該用戶的Session，給瀏覽器發送重定向指令，因為用戶已經登陸過，所以瀏覽器會在Http請求中附帶上TGC給ZAS Server。。

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

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

　　代理訪問時的驗證流程

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

　　一般模式下的驗證流程：

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

　　第一步：用戶訪問服務A的被保護資源，服務Ａ需要代理用戶訪問其他服務。

　　第二步：服務A發現沒有該用戶的Session，給瀏覽器發送重定向指令。

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

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

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

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

　　第七步：返回用戶名給服務A。

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

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

　　第十步：服務Ａ發送獲得的PT給服務Ｂ，請求代理。

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

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

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

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

　　注意：如果用戶已經登陸，則代理訪問時從第八步開始。

　　信任模式下的驗證流程：

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

　　第一步：用戶訪問服務A的被保護資源，服務Ａ需要代理用戶訪問其他服務。

　　第二步：服務A發現沒有該用戶的Session，給瀏覽器發送重定向指令。

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

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

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

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

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

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

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

　　注意：如果用戶已經登陸，則代理訪問時從第五步開始。