用户验证流程

　　用户未登陆时的验证流程

　　用户未在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提供数据。

　　第九步：服务Ａ接收到服务Ｂ的数据，完成服务的准备工作，将结果显示在用户的浏览器上，流程结束。

　　注意：如果用户已经登陆，则代理访问时从第五步开始。