当前位置:首页/帮助中心/ZAS(单点登录)/帮助文档

用户验证流程

作者:系统管理员   最后修改:2012年07月24日   浏览数: 773  

用户验证流程

 

  用户未登陆时的验证流程

  用户未在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获得服务A传过来的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需要代理用户访问其他服务。

  第二步:服务A发现没有该用户的Session,给浏览器发送重定向指令。

  第三步:浏览器重定向到ZAS Server,显示输入验证信息的页面。

  第四步:用户输入验证信息后,ZAS Server判断验证信息是否正确,如果不正确,流程中止。如果正确,则指示浏览器重定向到服务A,并将ST作为URL参数附加到服务A的URL上,同时将TGC传给浏览器,浏览器储存TGC。

  第五步:服务A获得ST,但服务A不知道该ST是否是伪造的,因此服务A将ST传给ZAS Server,判断ST是否正确。

  第六步:ZAS Server获得服务A传过来的ST,因为所有的ST都是由ZAS Server产生的,因此ZAS Server很容易判断ST是否正确。如果ST不正确,流程中止。如果正确,则反向调用服务A的ProxyCallbackURL将PGT和用户名传递给服务A。

  第七步:返回用户名给服务A。

  第八步:服务A确认该用户已经登陆,并得到了用户名,因此可以为该用户产生Session,然后准备提供服务给用户,但又发现需要服务B提供的数据才能进行,因此服务A发送PGT给ZAS Server以请求PT。

  第九步:ZAS Server检查PGT,如果PGT不正确,则流程中止,如果正确,则生成PT,返回给服务A。

  第十步:服务A发送获得的PT给服务B,请求代理。

  第十一步:服务B不知道PT是否是伪造的,因此服务B将PT发送给ZAS Server验证。

  第十二步:因此一般模式下的所有PT都是由ZAS Server生成的,所以ZAS Server很容易就能够判断PT是否正确,如果不正确,则流程中止,如果正确,则返回PT对应的用户名给服务B。

  第十三步:服务B确认代理有效,并得到了用户名,因此服务B可以为服务A提供数据。

  第十四步:服务A接收到服务B的数据,完成服务的准备工作,将结果显示在用户的浏览器上,流程结束。

  注意:如果用户已经登陆,则代理访问时从第八步开始。

  信任模式下的验证流程:

 

  如上图所示,信任模式下的验证流程如下:

  第一步:用户访问服务A的被保护资源,服务A需要代理用户访问其他服务。

  第二步:服务A发现没有该用户的Session,给浏览器发送重定向指令。

  第三步:浏览器重定向到ZAS Server,显示输入验证信息的页面。

  第四步:用户输入验证信息后,ZAS Server判断验证信息是否正确,如果不正确,流程中止。如果正确,则指示浏览器重定向到服务A,并用服务A的密钥加密后的用户名作为URL参数附加到服务A的URL上,同时将TGC传给浏览器,浏览器储存TGC。

  第五步:服务A接收到加密后的用户名,如果不能用自己的密钥解密,则说明传输过程中出现了异常(一般是被非法篡改),流程中止。如果能正确解密,则可以为该用户产生Session,然后准备提供服务给用户,但又发现需要服务B提供的数据才能进行,因此服务A用自己的密钥一个指定格式的加密PT并传递给服务B。

  第六步:服务B不知道PT是否是伪造的,因此服务B将此PT转发给ZAS Server请求验证。

  第七步:ZAS接收到PT,如果PT不能用服务A的密钥解密,则流程中止,如果能够正确解密,则返回PT对应的用户名给服务B。

  第八步:服务B确认代理有效,并得到了用户名,因此服务B可以为服务A提供数据。

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

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