关于CAS实现单点登录的思考

      最近要做单点登录，于是研究了两天CAS，对用户注册这个问题很纠结，有以下两种方式，不知哪个更好，期待大家讨论。

 

      1、Server端有DB，自己做好用户注册的实现，将接口提供给各个Client端（具体用什么方式让Client端调用是个难点，难点1）。

       这样的话，用户登录某一应用（CAS中的Client端）时，会被拦截，转到Server端，在Server端读数据库进行验证，验证通过后，返回到Client端，然后Client端再读自己的数据库，取出用户的信息（此处很纠结，因为各个Client的用户实体的属性是不一样的，比如有的Client端的用户有手机号这一属性，有的则没有，所以综合了一下，只希望在Server端存用户的用户名和密码）。

 

      2、Server端无DB，注册时到各Client端只把用户信息保存到各自的DB。

      这样的话，用户登录某一应用（CAS中的Client端）时，会被拦截，转到Server端，Server端根据请求的不同判断该调用哪个Client的DB进行验证（难点2），此处又要有分支了：

      1)、验证的时候把用户信息读出来，验证通过后，将用户信息直接传给Client端（难点3），这样Client端就不用再读DB提取用户信息了。

      2)、验证的时候不读用户的信息，验证通过后，返回到Client端，Client端再读用户信息。

 

大家觉的用什么方式好一些？并希望大家对标红的三个难点进行讨论。

 

 

这个帖子不错：http://www.iteye.com/topic/165313

 

BTW：

感谢大家的热情参与，特别鸣谢：wad12302、denger 、fallen_lord、lovit

大家可以看一下他们的发帖，会得到不少信息。

扩展CAS等具体做法请参照fallen_lord的发帖。

稍后我会参照他们的观点作出整理，loading..........

 

-----------------------------------分割线-----------------------------------------------------

 

现在正在实现着，等实现好了再把方案完整的贴出来。

采用的方式是REST，谢谢denger的建议，至于CAS怎么集成REST，大家可以去看denger博客上的文章：http://denger.iteye.com/blog/973068

 

loading...........

 

评论

34 楼 denger 2011-04-26  

fandayrockworld 写道

denger 写道

如果B系统再注册一下这种做法的话，要是你只有一两个字应用系统还好，如果你系统一多就麻烦了。 比如 A B C D  E F  系统， 在A中注册一个，我需要 调用  BCEFG中的所有注册接口。如果我在 F中注册一下，我需要在 ABCDE 各调用一下注册。

实际上我想说的是这种做法把简单的事情给复杂化了。而且仔细想想还会存在很多问题，在实际中～～

不是在A系统注册的时候就在BCDEF注册，而是从A转到BCDEF的时候，默默注册一下。
明天我把我的想法再整理一下，把各个点都想到，再贴出来吧。

还是一样的啊，如果从 a 转到 b 之后，如果你 a 不提供接口，那么 b 如何（获取用户名密码等信息） 默默注册？如果从b切换到 e ，如果b 不提供接口 e 如果默默注册？

我想说的是，只要你把 登录表 分到多个应用系统中，肯定就会存在数据同步的问题～

33 楼 fandayrockworld 2011-04-25  

denger 写道

fandayrockworld 写道

lovit 写道

fandayrockworld 写道

@罗卜头,@hszdz,@kjj
你们的观点都是支持1的。
但是CAS不做成1这样的方式肯定有他的考虑，就像楼上@wad12302说的：

引用

其实针对多个用户信息不同表情况 只是限于 继承原有系统，如果新系统 可能都会采取多个系统共用一个用户信息（只针对于企业应用系统）

就像这样：继承原有的系统的话，2明显要比1好。
可能CAS是出于这样的考虑吧。

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

将注册页面直接做在CAS Server端，注册时，只记录几个登录所要的字段如手机，用户名，密码，邮箱。注册成功后，登录子系统，然后跳出各子系统注册完善页（也就是各系统自己的扩展信息）。

引用

像注册，你可以做的CAS Server端只保存主要的用于登录的信息，到了客户端，你想怎么加附加属性都行啊。像QQ的应用，你登录时，不就是手机、邮箱、密码这类通用的信息，这些信息就保存在CAS Server端。进入各应用后，再完善扩展信息，如工作经验、性别、地区等，这个就好比QQ里围脖信息的完善，像QQ校友里的学校的设置等等。这样不就解决了。我们要从现有成熟的行业去分析与解决问题。

引用

像注册，你可以做的CAS Server端

我们尽量只把CAS当做一个黑盒来使用，不要轻易去修改它。
如果按照你说的方式的话（即给CAS增加一部分注册的功能），那么client端调用的时候呢，如果用不同语言去实现的话，是不是各个client端要写相应的实现啊。所以，CAS还是做他的验证，别的尽量别做。

在 server 端增加注册功能，并不需要修改它，而是扩展它。 对于client调用来说，我觉得也并不是什么大问题，如果采用  Rest 的方式, HTTP 协议调用，整个过程基本上不超过 10行代码,无论什么客户端。
另外CAS本身也提供了基于  Rest-APi 的登录、验证、注销；

HTTP协议调用？

32 楼 fandayrockworld 2011-04-25  

denger 写道

引用

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

都21世纪了，就这点东西还在 webservice? PHPRPC、REST 都是轻量级的经典啊～

还有一些其他的东西，不只是用户管理的这些功能，所以选择了单起一个服务。
无奈啊，没用过你说的其他两种东西，要学习了。。。

31 楼 fandayrockworld 2011-04-25  

denger 写道

如果B系统再注册一下这种做法的话，要是你只有一两个字应用系统还好，如果你系统一多就麻烦了。 比如 A B C D  E F  系统， 在A中注册一个，我需要 调用  BCEFG中的所有注册接口。如果我在 F中注册一下，我需要在 ABCDE 各调用一下注册。

实际上我想说的是这种做法把简单的事情给复杂化了。而且仔细想想还会存在很多问题，在实际中～～

不是在A系统注册的时候就在BCDEF注册，而是从A转到BCDEF的时候，默默注册一下。
明天我把我的想法再整理一下，把各个点都想到，再贴出来吧。

30 楼 fandayrockworld 2011-04-25  

denger 写道

引用

假如a_user中有一个用户：auser，b_user中有一个用户buser，这样你无论用哪一个用户登录，CAS就会先查a_user，如果用户名密码都正确，那么就通过，如果a_user中验证失败，那么CAS就会再查b_user，用户名密码都正确就算通过了，此时不正确，就算这次登录验证没通过。

我觉得这种验证方法不适合，如果我有N个子应用系统，那么是不是意味我有  n+_user  个表呢？ 一次登录，却需要 select n次，请问这样做合理吗？
如果在 buser 修改了密码? 这时候你如何去修改 auser 表中的密码呢?  如果不去修改就是造成我用修改前的密码也能在 auser的系统中登录，好象不太合理吧？莫非又是数据同步?

1、如果采取2那种方式的话，貌似select n次是最好的选择了吧。
2、的确不太合理，请明示。

29 楼 denger 2011-04-25  

fandayrockworld 写道

denger 写道

引用

在各个Client端注册，验证的话转到Server端，Server端可以配置很多个验证，只要一个验证通过了就算通过了，具体请参照：http://www.iteye.com/topic/165313

   先不说在哪注册，不知道你说的 Server配置很多个验证 是指什么？ 我想说的是验证肯定是 Server中进行验证。

关于验证：
    首页中的描述可能有些问题，标点符号加的太飘逸，请结合上下文看。
    应该改为：
   

引用

注册在client端做，登录时的验证在server端（CAS本来有的功能，不应该加这一句话）

denger 写道

引用

2、Server端无DB，注册时到各Client端只把用户信息保存到各自的DB。
      这样的话，用户登录某一应用（CAS中的Client端）时，会被拦截，转到Server端，Server端根据请求的不同判断该调用哪个Client的DB进行验证（难点2），此处又要有分支了：
      1)、验证的时候把用户信息读出来，验证通过后，将用户信息直接传给Client端（难点3），这样Client端就不用再读DB提取用户信息了。
      2)、验证的时候不读用户的信息，验证通过后，返回到Client端，Client端再读用户信息。

这种方法会存在很多问题，如果每个应用系统都保存了各自的用户的话，采用什么方法进行 数据同步？比如我在 A 系统注册后，难道还我还要去 B 系统中再注册一下。 当然，你可以说使用db 数据同步或通过程序的方式。另外还有一个很实际的问题就是 很难确保每个系统中采取相同的加密算法对密码进行加密。

如果采取2的这种做法的话，只能是采取

引用

B 系统中再注册一下

的方法了，当然，如果B系统中注册时所需要的字段从A中都能获得，那么系统“默默的”自动注册就行；否则，就得提供用户填写必要信息的注册页面了。。

如果B系统再注册一下这种做法的话，要是你只有一两个字应用系统还好，如果你系统一多就麻烦了。 比如 A B C D  E F  系统， 在A中注册一个，我需要 调用  BCEFG中的所有注册接口。如果我在 F中注册一下，我需要在 ABCDE 各调用一下注册。

引用

就得提供用户填写必要信息的注册页面了。。

这样并非好的方法，而且也不符合逻辑。 明明 abcdefg都你们公司的系统，我在 a 中注册了，为什么还要到 b中再注册一个?   因为实际上sso的目的本身就是方便用户的一件事情。


实际上我想说的是这种做法把简单的事情给复杂化了。而且仔细想想还会存在很多问题，在实际中～～

28 楼 denger 2011-04-25  

fandayrockworld 写道

lovit 写道

fandayrockworld 写道

@罗卜头,@hszdz,@kjj
你们的观点都是支持1的。
但是CAS不做成1这样的方式肯定有他的考虑，就像楼上@wad12302说的：

引用

其实针对多个用户信息不同表情况 只是限于 继承原有系统，如果新系统 可能都会采取多个系统共用一个用户信息（只针对于企业应用系统）

就像这样：继承原有的系统的话，2明显要比1好。
可能CAS是出于这样的考虑吧。

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

将注册页面直接做在CAS Server端，注册时，只记录几个登录所要的字段如手机，用户名，密码，邮箱。注册成功后，登录子系统，然后跳出各子系统注册完善页（也就是各系统自己的扩展信息）。

引用

像注册，你可以做的CAS Server端只保存主要的用于登录的信息，到了客户端，你想怎么加附加属性都行啊。像QQ的应用，你登录时，不就是手机、邮箱、密码这类通用的信息，这些信息就保存在CAS Server端。进入各应用后，再完善扩展信息，如工作经验、性别、地区等，这个就好比QQ里围脖信息的完善，像QQ校友里的学校的设置等等。这样不就解决了。我们要从现有成熟的行业去分析与解决问题。

引用

像注册，你可以做的CAS Server端

我们尽量只把CAS当做一个黑盒来使用，不要轻易去修改它。
如果按照你说的方式的话（即给CAS增加一部分注册的功能），那么client端调用的时候呢，如果用不同语言去实现的话，是不是各个client端要写相应的实现啊。所以，CAS还是做他的验证，别的尽量别做。

在 server 端增加注册功能，并不需要修改它，而是扩展它。 对于client调用来说，我觉得也并不是什么大问题，如果采用  Rest 的方式, HTTP 协议调用，整个过程基本上不超过 10行代码,无论什么客户端。
另外CAS本身也提供了基于  Rest-APi 的登录、验证、注销；

27 楼 fandayrockworld 2011-04-25  

denger 写道

引用

在各个Client端注册，验证的话转到Server端，Server端可以配置很多个验证，只要一个验证通过了就算通过了，具体请参照：http://www.iteye.com/topic/165313

   先不说在哪注册，不知道你说的 Server配置很多个验证 是指什么？ 我想说的是验证肯定是 Server中进行验证。

关于验证：
    首页中的描述可能有些问题，标点符号加的太飘逸，请结合上下文看。
    应该改为：
   

引用

注册在client端做，登录时的验证在server端（CAS本来有的功能，不应该加这一句话）

denger 写道

引用

2、Server端无DB，注册时到各Client端只把用户信息保存到各自的DB。
      这样的话，用户登录某一应用（CAS中的Client端）时，会被拦截，转到Server端，Server端根据请求的不同判断该调用哪个Client的DB进行验证（难点2），此处又要有分支了：
      1)、验证的时候把用户信息读出来，验证通过后，将用户信息直接传给Client端（难点3），这样Client端就不用再读DB提取用户信息了。
      2)、验证的时候不读用户的信息，验证通过后，返回到Client端，Client端再读用户信息。

这种方法会存在很多问题，如果每个应用系统都保存了各自的用户的话，采用什么方法进行 数据同步？比如我在 A 系统注册后，难道还我还要去 B 系统中再注册一下。 当然，你可以说使用db 数据同步或通过程序的方式。另外还有一个很实际的问题就是 很难确保每个系统中采取相同的加密算法对密码进行加密。

如果采取2的这种做法的话，只能是采取

引用

B 系统中再注册一下

的方法了，当然，如果B系统中注册时所需要的字段从A中都能获得，那么系统“默默的”自动注册就行；否则，就得提供用户填写必要信息的注册页面了。。

26 楼 denger 2011-04-25  

引用

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

都21世纪了，就这点东西还在 webservice? PHPRPC、REST 都是轻量级的经典啊～

25 楼 denger 2011-04-25  

kjj 写道

就我的使用cas来说,用户信息肯定要统一起来

各个client如果都有自己的用户数据库那么就失去用户信息的意义了

这些其实相当于一个普通的用户相关信息

真正的用户名密码都只有一套

是的，可以将用户基础及通用（邮箱、登录名、性别等等之类的）的东西抽出来放在 cas 中。

24 楼 denger 2011-04-25  

引用

假如a_user中有一个用户：auser，b_user中有一个用户buser，这样你无论用哪一个用户登录，CAS就会先查a_user，如果用户名密码都正确，那么就通过，如果a_user中验证失败，那么CAS就会再查b_user，用户名密码都正确就算通过了，此时不正确，就算这次登录验证没通过。

我觉得这种验证方法不适合，如果我有N个子应用系统，那么是不是意味我有  n+_user  个表呢？ 一次登录，却需要 select n次，请问这样做合理吗？
如果在 buser 修改了密码? 这时候你如何去修改 auser 表中的密码呢?  如果不去修改就是造成我用修改前的密码也能在 auser的系统中登录，好象不太合理吧？莫非又是数据同步?

23 楼 denger 2011-04-25  

引用

在各个Client端注册，验证的话转到Server端，Server端可以配置很多个验证，只要一个验证通过了就算通过了，具体请参照：http://www.iteye.com/topic/165313

   先不说在哪注册，不知道你说的 Server配置很多个验证 是指什么？ 我想说的是验证肯定是 Server中进行验证。

引用

2、Server端无DB，注册时到各Client端只把用户信息保存到各自的DB。
      这样的话，用户登录某一应用（CAS中的Client端）时，会被拦截，转到Server端，Server端根据请求的不同判断该调用哪个Client的DB进行验证（难点2），此处又要有分支了：
      1)、验证的时候把用户信息读出来，验证通过后，将用户信息直接传给Client端（难点3），这样Client端就不用再读DB提取用户信息了。
      2)、验证的时候不读用户的信息，验证通过后，返回到Client端，Client端再读用户信息。

这种方法会存在很多问题，如果每个应用系统都保存了各自的用户的话，采用什么方法进行 数据同步？比如我在 A 系统注册后，难道还我还要去 B 系统中再注册一下。 当然，你可以说使用db 数据同步或通过程序的方式。另外还有一个很实际的问题就是 很难确保每个系统中采取相同的加密算法对密码进行加密。

另外一个就是大大违背了 CAS 的原则，本身就是一个统一认证服务中心，为什么还要在各自应用系统提供用户验证接口？

22 楼 lovit 2011-04-25  

fandayrockworld 写道

lovit 写道

fandayrockworld 写道

lovit 写道

这个注册功能，就像登录面，根本就不用考虑不同的语言啊，你登录页不是也在CAS Server端吗？？

假如现在有两个client端，分别是PHP和java做的，那么你在各个client端调用CAS现有的功能，要加入CAS提供的不同的client端实现（PHP的加PHP的client端实现，JAVA的加JAVA的client端实现），所以，你要是再给CAS加功能的话，那请问，你是不是要在这些CAS提供的client端实现里也要加东西才能调用？
请仔细考虑一下。。。

你可能没有仔细看我的方案。
注册的时候，是不是一个页面？这就好比一个登录页，你将注册页用做好，放在CAS Server端，访问注册的地址是：
https://单点登录服务器地址/register  ，但是这个只记录验证相关的信息，也就是用户名与密码，还可以是邮箱。

然然各子系统不就可以登录了？因为有用户名和密码了。
A子系统是一个围脖（是PHP语言做的），那么可能还要加一些扩展信息，性别、生日、年龄等，那你就在登录完成你这个A子系统（围脖）后，用向导来完善你自己系统的内容（PHP来做的）
B子系统是一个同学录（JAVA语言来做的），那么可能还要加一些学校，爱好等扩展信息，那么和上面方法一样，你在B子系统，用JAVA来实现用户扩展信息向导。

OK，就到这里。

对啊，的确可行，没考虑到，呵呵，谢了。

这样的好处是双系统同用一个用户密码，就是TENCENT那样。这绝对是最好的实践之一。当然，双用户表也可以，但如果密码不同步，那么会有不同密码，都可以登录系统的问题。

21 楼 fandayrockworld 2011-04-25  

lovit 写道

fandayrockworld 写道

lovit 写道

这个注册功能，就像登录面，根本就不用考虑不同的语言啊，你登录页不是也在CAS Server端吗？？

假如现在有两个client端，分别是PHP和java做的，那么你在各个client端调用CAS现有的功能，要加入CAS提供的不同的client端实现（PHP的加PHP的client端实现，JAVA的加JAVA的client端实现），所以，你要是再给CAS加功能的话，那请问，你是不是要在这些CAS提供的client端实现里也要加东西才能调用？
请仔细考虑一下。。。

你可能没有仔细看我的方案。
注册的时候，是不是一个页面？这就好比一个登录页，你将注册页用做好，放在CAS Server端，访问注册的地址是：
https://单点登录服务器地址/register  ，但是这个只记录验证相关的信息，也就是用户名与密码，还可以是邮箱。

然然各子系统不就可以登录了？因为有用户名和密码了。
A子系统是一个围脖（是PHP语言做的），那么可能还要加一些扩展信息，性别、生日、年龄等，那你就在登录完成你这个A子系统（围脖）后，用向导来完善你自己系统的内容（PHP来做的）
B子系统是一个同学录（JAVA语言来做的），那么可能还要加一些学校，爱好等扩展信息，那么和上面方法一样，你在B子系统，用JAVA来实现用户扩展信息向导。

OK，就到这里。

对啊，的确可行，没考虑到，呵呵，谢了。

20 楼 lovit 2011-04-25  

fandayrockworld 写道

lovit 写道

这个注册功能，就像登录面，根本就不用考虑不同的语言啊，你登录页不是也在CAS Server端吗？？

假如现在有两个client端，分别是PHP和java做的，那么你在各个client端调用CAS现有的功能，要加入CAS提供的不同的client端实现（PHP的加PHP的client端实现，JAVA的加JAVA的client端实现），所以，你要是再给CAS加功能的话，那请问，你是不是要在这些CAS提供的client端实现里也要加东西才能调用？
请仔细考虑一下。。。

你可能没有仔细看我的方案。
注册的时候，是不是一个页面？这就好比一个登录页，你将注册页用做好，放在CAS Server端，访问注册的地址是：
https://单点登录服务器地址/register  ，但是这个只记录验证相关的信息，也就是用户名与密码，还可以是邮箱。

然然各子系统不就可以登录了？因为有用户名和密码了。
A子系统是一个围脖（是PHP语言做的），那么可能还要加一些扩展信息，性别、生日、年龄等，那你就在登录完成你这个A子系统（围脖）后，用向导来完善你自己系统的内容（PHP来做的）
B子系统是一个同学录（JAVA语言来做的），那么可能还要加一些学校，爱好等扩展信息，那么和上面方法一样，你在B子系统，用JAVA来实现用户扩展信息向导。

OK，就到这里。

19 楼 fandayrockworld 2011-04-25  

lovit 写道

这个注册功能，就像登录面，根本就不用考虑不同的语言啊，你登录页不是也在CAS Server端吗？？

假如现在有两个client端，分别是PHP和java做的，那么你在各个client端调用CAS现有的功能，要加入CAS提供的不同的client端实现（PHP的加PHP的client端实现，JAVA的加JAVA的client端实现），所以，你要是再给CAS加功能的话，那请问，你是不是要在这些CAS提供的client端实现里也要加东西才能调用？
请仔细考虑一下。。。

18 楼 lovit 2011-04-25  

fandayrockworld 写道

lovit 写道

fandayrockworld 写道

@罗卜头,@hszdz,@kjj
你们的观点都是支持1的。
但是CAS不做成1这样的方式肯定有他的考虑，就像楼上@wad12302说的：

引用

其实针对多个用户信息不同表情况 只是限于 继承原有系统，如果新系统 可能都会采取多个系统共用一个用户信息（只针对于企业应用系统）

就像这样：继承原有的系统的话，2明显要比1好。
可能CAS是出于这样的考虑吧。

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

将注册页面直接做在CAS Server端，注册时，只记录几个登录所要的字段如手机，用户名，密码，邮箱。注册成功后，登录子系统，然后跳出各子系统注册完善页（也就是各系统自己的扩展信息）。

引用

像注册，你可以做的CAS Server端只保存主要的用于登录的信息，到了客户端，你想怎么加附加属性都行啊。像QQ的应用，你登录时，不就是手机、邮箱、密码这类通用的信息，这些信息就保存在CAS Server端。进入各应用后，再完善扩展信息，如工作经验、性别、地区等，这个就好比QQ里围脖信息的完善，像QQ校友里的学校的设置等等。这样不就解决了。我们要从现有成熟的行业去分析与解决问题。

引用

像注册，你可以做的CAS Server端

我们尽量只把CAS当做一个黑盒来使用，不要轻易去修改它。
如果按照你说的方式的话（即给CAS增加一部分注册的功能），那么client端调用的时候呢，如果用不同语言去实现的话，是不是各个client端要写相应的实现啊。所以，CAS还是做他的验证，别的尽量别做。

这个注册功能，就像登录面，根本就不用考虑不同的语言啊，你登录页不是也在CAS Server端吗？？

17 楼 fandayrockworld 2011-04-25  

lovit 写道

fandayrockworld 写道

@罗卜头,@hszdz,@kjj
你们的观点都是支持1的。
但是CAS不做成1这样的方式肯定有他的考虑，就像楼上@wad12302说的：

引用

其实针对多个用户信息不同表情况 只是限于 继承原有系统，如果新系统 可能都会采取多个系统共用一个用户信息（只针对于企业应用系统）

就像这样：继承原有的系统的话，2明显要比1好。
可能CAS是出于这样的考虑吧。

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

将注册页面直接做在CAS Server端，注册时，只记录几个登录所要的字段如手机，用户名，密码，邮箱。注册成功后，登录子系统，然后跳出各子系统注册完善页（也就是各系统自己的扩展信息）。

引用

像注册，你可以做的CAS Server端只保存主要的用于登录的信息，到了客户端，你想怎么加附加属性都行啊。像QQ的应用，你登录时，不就是手机、邮箱、密码这类通用的信息，这些信息就保存在CAS Server端。进入各应用后，再完善扩展信息，如工作经验、性别、地区等，这个就好比QQ里围脖信息的完善，像QQ校友里的学校的设置等等。这样不就解决了。我们要从现有成熟的行业去分析与解决问题。

引用

像注册，你可以做的CAS Server端

我们尽量只把CAS当做一个黑盒来使用，不要轻易去修改它。
如果按照你说的方式的话（即给CAS增加一部分注册的功能），那么client端调用的时候呢，如果用不同语言去实现的话，是不是各个client端要写相应的实现啊。所以，CAS还是做他的验证，别的尽量别做。

16 楼 lovit 2011-04-25  

fandayrockworld 写道

@罗卜头,@hszdz,@kjj
你们的观点都是支持1的。
但是CAS不做成1这样的方式肯定有他的考虑，就像楼上@wad12302说的：

引用

其实针对多个用户信息不同表情况 只是限于 继承原有系统，如果新系统 可能都会采取多个系统共用一个用户信息（只针对于企业应用系统）

就像这样：继承原有的系统的话，2明显要比1好。
可能CAS是出于这样的考虑吧。

另外，纠结了好多天，最终采用的却是1：
但是用户注册等的实现是通过另起一个webservice服务的方式实现的，用webservice的原因是，这个接口可能会php、java等多种语言调用，实在想不出什么更好的方式了，就用了webservice。
大家有更好的方式吗？

将注册页面直接做在CAS Server端，注册时，只记录几个登录所要的字段如手机，用户名，密码，邮箱。注册成功后，登录子系统，然后跳出各子系统注册完善页（也就是各系统自己的扩展信息）。

引用

像注册，你可以做的CAS Server端，只保存主要的用于登录的信息，到了客户端，你想怎么加附加属性都行啊。像QQ的应用，你登录时，不就是手机、邮箱、密码这类通用的信息，这些信息就保存在CAS Server端。进入各应用后，再完善扩展信息，如工作经验、性别、地区等，这个就好比QQ里围脖信息的完善，像QQ校友里的学校的设置等等。这样不就解决了。我们要从现有成熟的行业去分析与解决问题。

15 楼 fandayrockworld 2011-04-25  

lovit 写道

不过在某些情况下，如现有不同系统的整合，用户密码信息也可以放在不同的客户端。CAS Server不是支持多个数据源，一个接一个验证吗？

嗯，正解。