根据我们的需求,用户的体验一般有两种:
一、对于使用多个子系统的用户,将有可能直接登录统一认证系统,并通过统一系统的子系统连接列表,跳转到多个子系统;二、对于一些使用单个子系统,或者自为单具体事情进入我们平台,或者是登录超时了,这是他应该向直接进入特定子系统,那么我们需要将登录验证在他进入子系统之前插入。两种不同方式的三个系统之间的交互过程如下图所示:
图 1. 一般步骤,同时登录多个子系统
图 2. 直接进入子系统,子系统之间跳转
我将按照第一种交互方式进行解释:
1、用户先与统一登录系统进行交互,使用唯一的帐号密码进行登录,此时不涉及任何子系统;
2、用户登录成功后,统一登录系统将信任的应用子系统列表呈现给用户;
3、用户根据需要,选择子系统连接访问子系统,用户与子系统的交互开始;
4、由于用户与子系统此时还没有建立认证关系,所以子系统将用户重定向到统一登录系统;
5、统一登录系统验证用户的登录信息,发现用户已经登录,便将登录信息插入到数据库,再将验证信息发给用户,即返回一个等待页面;
6、用户将等待页面中的验证信息提交(自动)到子系统,子系统获取认证信息;
7、子系统通过一定的办法和等待页面中的验证信息进行验证,并与用户建立了信任关系;
与ASP.NET封装的实现方案项目,这交互过程看起来十分烦碎,我们还需要自己实现大量的功能。但我们的交互实现过程都是可控的,各个系统之间传递的信息内容,什么时候传递,我能都可以限制和约定,并且能够将每一次系统之间的交互记录都进行登记,这才是我们需要的。至于烦碎,其实对用户来说,增加的步骤就是出现自动提交的等待登录页面,如果两个系统都能正常运行,网络也没有出现堵塞,用户等待的时间将及其短暂,甚至没能看到页面。并且我们能够对等待页面做一定的美化,使用户就算看到等待页面,也不会感到厌烦。
说了这么多,统一认证系统的应用子系统Session的共享还没有开始,这是本方案最大的难点......