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