关于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...........

 

评论

54 楼 fandayrockworld 2011-04-26  

denger 写道

楼主，把贴子中的

引用

大家可以无视上面的问题了，晕了，在Server端注册本身就是一个很扯淡的命题，用不着，怪不得CAS不提供注册的接口和实现。

修一下，免得误导别人。
另外

引用

CAS的经典做法是：在各个Client端注册，验证的话转到Server端，Server端可以配置很多个验证，只要一个验证通过了就算通过了

这确实不是经典的做法，一般都不会这么做的，无特殊情况 SERVER 端配置一个验证就行了 ，可以看看 cas官方的基于j2ee的例子。

忙了一天，没来得及回复帖子。这就改改。

53 楼 denger 2011-04-26  

楼主，把贴子中的

引用

大家可以无视上面的问题了，晕了，在Server端注册本身就是一个很扯淡的命题，用不着，怪不得CAS不提供注册的接口和实现。

修一下，免得误导别人。
另外

引用

CAS的经典做法是：在各个Client端注册，验证的话转到Server端，Server端可以配置很多个验证，只要一个验证通过了就算通过了

这确实不是经典的做法，一般都不会这么做的，无特殊情况 SERVER 端配置一个验证就行了 ，可以看看 cas官方的基于j2ee的例子。

52 楼 wad12302 2011-04-26  

恩！
谢谢大家的细心解答！

51 楼 rambler 2011-04-26  

建一个集中注册和维护的用户信息库，仅存放通用信息，例如身份证号、员工编号、姓名和口令等等，CAS在此用户库上进行集中认证。
    当用户通过CAS验证访问客户端应用时，CAS传递用户凭证（身份证号、员工编号、姓名），客户端须判断该用户凭证是否在本系统中存在，如果已存在则自动进入系统，并遵循客户端权限管理；
    如果用户凭证在客户端应用中没有保存过，则根据业务需要判断CAS提供的用户通用信息是否足够用，若够用直接后台写入本系统用户表，然后进入系统；如果还需补充其它信息则弹出注册页面，显示通用信息，用户补充填入其它信息后提交，这样用户下次再访问本系统时就可以自动进入；
    如果用户在业务系统中原本就有账户信息（在单点登录系统实施前的旧系统），则在上诉注册页面让用户选择绑定原有账户，输入原客户端应用的登录名和登录口令，验证通过后将用户的CAS凭证和旧账户绑定保存在客户端用户表中，这样用户再次访问客户端应用时就可以使用原账户的相关信息。

50 楼 wad12302 2011-04-26  

@denger
可能我所说的 涉及其他的 楼上 理解的范围业务太广了，我所指的没那么多。

业务逻辑都是与单点登录分离。

但我刚才所说并不是全指这个：
比如现有各个系统（旧系统）分开，每个系统有自己的用户表，如果不采取用户集中管理，那么采用链式查询登录后：
A系统用户登录到B系统时候（第一次访问，只能获取id，等等一些基础信息），查看某些B系统特定功能权限，那么这个权限问题（是在那边分配，应为旧系统每个系统都有自己的权限管理，现在使用单点登录了，其他系统访问后怎么分配，如果今后又多几个系统集成进来呢）

所以，这里并没有涉及过多的系统的业务逻辑，只是影响到集成单点登录后，用户信息同步或者接口调用问题，其实也只是一个初始化问题。
我也觉得要有改动的也只是这个部分存在改动（不使用统一管理，LDAP），其他业务逻辑已经跟单点登录分离了，这个也是一个单点登录项目的开发者与项目应用者所站的角度不同。


其实大家讨论了这么多，对我是很有用的，问题的提出只是应为我看了讨论后才产生的，只是想多了解下方案。

49 楼 denger 2011-04-26  

wad12302 写道

这个的第3点 只是 应为 当时 说的 采用多库链式查找用户信息，那么如果没有数据同步或者同义词之类的（集成原有系统），，在各个系统中可能没有该用户信息，访问某些特定东西 肯定涉及权限问题，所以这个权限要怎么兼容进来（没有采用统一管理用户信息，当然像前面说的，对多个系统进行用户统一管理后这种问题就不存在）


还有就是讨论中所说的,cas 只涉及到单点登录 不涉及其他，我个人认为这样理解不妥
就职能来说 只是验证，但是还有一个重点就是 验证之后呢，这就要考虑到这个系统的改动问题
不能单单应为一个功能而忽略了整个系统现在的状态，怎么做到集成进来了可以把改动降低最小（功能涉及）
毕竟新的系统好解决，集成原N年系统就要考虑
所以大家讨论的不应只是限在点点登录而应该考虑所涉及范围

为什么大家一直说

引用

cas 只涉及到单点登录 不涉及其他

，其目的就是

引用

做到集成进来了可以把改动降低最小

，由其是对于老系统来说更是如此。 CAS 只涉及单点登录的主要是降低应用系统与 CAS 的偶合度，当我需要将某个应用系统集成至 CAS  中时候，我只需要修改它的登录处理、注销、是否已经登录的校验(如果通过Filter的话基本不需要修改，只需要增加未登录跳转的地址即可，并且cas -client提供好很好扩展机制，如自定义登录成功之后的业务逻辑，自定义登录失败的业务逻辑，从Session中获取当前登录用户，这些都可以自定义)。 其它 一般都不需要进行修改，你根本不需要管现在系统的业务状态（当然，如果你权限偶合度及设计是足够烂就没得说了，我以前见过直接在 jsp 上判断是否允许访问校验代码）。 我们以前整合过一个公司购买的 支付系统，它的权限机制及业务也是非常的复杂的，但是实际过程改动实际上非常小~

48 楼 denger 2011-04-26  

lovit 写道

denger 写道

lovit 写道

1、无论是CAS1.0还是CAS2.0，都可以返回CAS Server端保存的通用信息（不仅是UserId）。
2、子系统还是保存用户扩展信息为好，通用信息（如用户名，密码）还是在CAS Server端为好。
3、如果不同子系统一定要有用户名密码，CAS当然是可以解决的，但如果是在企业内部的应用，用户密码同步是一个麻烦的问题，注册也要同步。当然，像一个在线冲印的网站与一个像片管理的网站，是不同的管理员，数据库也不可能共享，CAS也解决不了，只能是OAuth之类能解决的了。

你说的这个cas是可以解决的： CAS Proxy～

用户同名了呢，，CAS Proxy的应用场景不是这样的。我说的这种情况，我想CAS很难解决的。主要是用户同名，有可能不是同一用户的原因。

首先我想说的是，还是那句，cas 只管认证、颁发ticket，用户名同名本身就不是它应该解决的问题.

另外，对于用户名同名的问题，我觉得只有你想合并多个应用用户数据库把它并成一个统一中央库的情况才会发生。

比如说如果某个用户想同时使用 在线冲印 或 像片管理，这时候的业务场景是只要这个用户在一个系统中授权通过后就可以使用另外一个系统的呢，还是说必须两个系统都需要对其进行用户名和密码的认证（虽然还是在cas-server认证），换句话说必须这个用户在这两个库中都在要存在，不管其是否同名。把这个弄清楚了之后就好说了。

而我这里所说的 cas proxy实际上解决第一种业务需求的情况下使用的，如果这个用户允许能够登录 “在线冲印”，那么可以通过  “在线冲印” proxy 登录 “像片管理”， 只需要CAS为你生成访问另外一个应用系统的PGT（与TGT类似），获取到PGT后为另外一个需要授权访问的系统生成一个 PT(类似ST) ，这时候你就可以使用 PT 在 "像片管理" 中登录使用了，之所以可以在“象片管理”中进行使用，是因为“像会片管理”信任 CAS SERVER 的 pT,认为这个用户在“在线冲印”中已经验证成功。 当然这只是一个大概的思路，实际上还是存在一定的问题需要解决。
  

对于第二种业务需求的话就需要双向验证了。
    
    

47 楼 wad12302 2011-04-26  

denger 写道

wad12302 写道

谢谢！

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


还有一点就是对于多数据源问题，这个对于认证时候可以选择：

但是我主要是想表达另一个问题是：用户信息问题（也只是企业应用，基于原有系统集成）
系统A   a_user

系统B   b_user


当用户A单点登录到B系统时候 那么B系统对A用户的权限验证问题（B系统中没有A的用户信息，是否需要数据同步），

通过2个数据源链式访问验证用户，那么过后对于 一些操作（读取，删除）权限的验证 有没有什么好的策略进行延伸


也许这个问题已经不是单点登录问题？？

主要想知道有什么好的机制

1.  采用多个数据源的解决方案，实际上也有应用场合限定的。有些不是你们开发的子系统你就不一定能够直接访问他们的用户数据库。
2.  关于企业应用的话在原有系统上进行  SSO 集成的话，除了我上面说的方案外还可以使用 CAS 中的 LDAP 方式。 最典型的应用场景就是： 公司 某个OA系统，是cas的其中一个client应用，然后公司希望在 mail.compay.com 公司邮箱下的所用用户都能登录OA系统，并且在mail 中登录后，可以直接切换到 oA 中，不需要重新登录。
3.至于你说的关于 读取删除之类的权限验证，确实与 SSO 没什么关系了，SSO 只管对 验证通过的用户颁发访问指定应用系统的ticket。其它权限之类由子应用系统处理。

这个的第3点 只是 应为 当时 说的 采用多库链式查找用户信息，那么如果没有数据同步或者同义词之类的（集成原有系统），，在各个系统中可能没有该用户信息，访问某些特定东西 肯定涉及权限问题，所以这个权限要怎么兼容进来（没有采用统一管理用户信息，当然像前面说的，对多个系统进行用户统一管理后这种问题就不存在）


还有就是讨论中所说的,cas 只涉及到单点登录 不涉及其他，我个人认为这样理解不妥
就职能来说 只是验证，但是还有一个重点就是 验证之后呢，这就要考虑到这个系统的改动问题
不能单单应为一个功能而忽略了整个系统现在的状态，怎么做到集成进来了可以把改动降低最小（功能涉及）
毕竟新的系统好解决，集成原N年系统就要考虑
所以大家讨论的不应只是限在点点登录而应该考虑所涉及范围

46 楼 huangyunhui 2011-04-26  

采用用户中心结构，提供注册接口，注册后在子系统添加所需的属性。

45 楼 lovit 2011-04-26  

denger 写道

lovit 写道

1、无论是CAS1.0还是CAS2.0，都可以返回CAS Server端保存的通用信息（不仅是UserId）。
2、子系统还是保存用户扩展信息为好，通用信息（如用户名，密码）还是在CAS Server端为好。
3、如果不同子系统一定要有用户名密码，CAS当然是可以解决的，但如果是在企业内部的应用，用户密码同步是一个麻烦的问题，注册也要同步。当然，像一个在线冲印的网站与一个像片管理的网站，是不同的管理员，数据库也不可能共享，CAS也解决不了，只能是OAuth之类能解决的了。

你说的这个cas是可以解决的： CAS Proxy～

用户同名了呢，，CAS Proxy的应用场景不是这样的。我说的这种情况，我想CAS很难解决的。主要是用户同名，有可能不是同一用户的原因。

44 楼 denger 2011-04-26  

lovit 写道

1、无论是CAS1.0还是CAS2.0，都可以返回CAS Server端保存的通用信息（不仅是UserId）。
2、子系统还是保存用户扩展信息为好，通用信息（如用户名，密码）还是在CAS Server端为好。
3、如果不同子系统一定要有用户名密码，CAS当然是可以解决的，但如果是在企业内部的应用，用户密码同步是一个麻烦的问题，注册也要同步。当然，像一个在线冲印的网站与一个像片管理的网站，是不同的管理员，数据库也不可能共享，CAS也解决不了，只能是OAuth之类能解决的了。

你说的这个cas是可以解决的： CAS Proxy～

43 楼 lovit 2011-04-26  

1、无论是CAS1.0还是CAS2.0，都可以返回CAS Server端保存的通用信息（不仅是UserId）。
2、子系统还是保存用户扩展信息为好，通用信息（如用户名，密码）还是在CAS Server端为好。
3、如果不同子系统一定要有用户名密码，CAS当然是可以解决的，但如果是在企业内部的应用，用户密码同步是一个麻烦的问题，注册也要同步。当然，像一个在线冲印的网站与一个像片管理的网站，是不同的管理员，数据库也不可能共享，CAS也解决不了，只能是OAuth之类能解决的了。

42 楼 罗卜头 2011-04-26  

fallen_lord 写道

楼主提得问题其实和CAS没啥关系
CAS不管注册，只管认证

至于提得几个方案，显然应该是方案一
楼主提的方案二Server端无DB的情况，是有很大问题的，会造成水桶状安全问题。如果认证源分布在n个客户端，那么一旦任意一个客户端被攻破，黑客就可以通过那个客户端完整的单点登陆所有其他的客户端。也就是说任一客户端被攻破表示整个SSO体系就崩溃了，这也是CAS一直在避免的问题（CAS连认证页面都不允许从客户端提交，Cookie也绝对存在自己域下而非根域）

方案一中的纠结的地方其实是正确的情况，每个客户端都有不同结构的用户数据，所以CAS协议（1.0和2.0都是）只会返回username一项给客户端，之后的事情就都是客户端自己处理的了，包括用户信息，权限，二次认证啥的

至于方案一中的难点为客户端开放注册接口，则完全是另外一码事儿，与CAS完全无关。这里楼主可以考虑几种方案：
1. 直接开放认证源权限（如对客户端开放ldap权限或是DB的权限）
2. 开放OpenAPI（如RESTful、WebService接口等，可以用CAS Proxy进行认证）
3. 定期去各个客户端拉取

不论用哪种方式，都需要控制客户端权限，可以考虑复杂如ACL，或是简单如仅允许insert不允许modify和delete等方式（这样即使黑客可以增加认证凭据却没有办法提升其他系统对此凭据的权限控制，由于不能修改所以也无法获取其他凭据的权限）。当然最好得是仅在中央认证服务器上注册，做到“绝不相信其他人”。

至于几个认证源、DB、LDAP/AD还是OpenSSO都无所谓，只是部署维护成本的问题，一个DB的多个表也可以看做多个认证源，配合数据库的权限控制也可以很好的满足楼主的需求

反正总而言之用户注册不是CAS责任范围，所以只能自己想办法

你妹,还不睡觉.

41 楼 fallen_lord 2011-04-26  

楼主提得问题其实和CAS没啥关系
CAS不管注册，只管认证

至于提得几个方案，显然应该是方案一
楼主提的方案二Server端无DB的情况，是有很大问题的，会造成水桶状安全问题。如果认证源分布在n个客户端，那么一旦任意一个客户端被攻破，黑客就可以通过那个客户端完整的单点登陆所有其他的客户端。也就是说任一客户端被攻破表示整个SSO体系就崩溃了，这也是CAS一直在避免的问题（CAS连认证页面都不允许从客户端提交，Cookie也绝对存在自己域下而非根域）

方案一中的纠结的地方其实是正确的情况，每个客户端都有不同结构的用户数据，所以CAS协议（1.0和2.0都是）只会返回username一项给客户端，之后的事情就都是客户端自己处理的了，包括用户信息，权限，二次认证啥的

至于方案一中的难点为客户端开放注册接口，则完全是另外一码事儿，与CAS完全无关。这里楼主可以考虑几种方案：
1. 直接开放认证源权限（如对客户端开放ldap权限或是DB的权限）
2. 开放OpenAPI（如RESTful、WebService接口等，可以用CAS Proxy进行认证）
3. 定期去各个客户端拉取

不论用哪种方式，都需要控制客户端权限，可以考虑复杂如ACL，或是简单如仅允许insert不允许modify和delete等方式（这样即使黑客可以增加认证凭据却没有办法提升其他系统对此凭据的权限控制，由于不能修改所以也无法获取其他凭据的权限）。当然最好得是仅在中央认证服务器上注册，做到“绝不相信其他人”。

至于几个认证源、DB、LDAP/AD还是OpenSSO都无所谓，只是部署维护成本的问题，一个DB的多个表也可以看做多个认证源，配合数据库的权限控制也可以很好的满足楼主的需求

反正总而言之用户注册不是CAS责任范围，所以只能自己想办法

40 楼 denger 2011-04-26  

wad12302 写道

谢谢！

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


还有一点就是对于多数据源问题，这个对于认证时候可以选择：

但是我主要是想表达另一个问题是：用户信息问题（也只是企业应用，基于原有系统集成）
系统A   a_user

系统B   b_user


当用户A单点登录到B系统时候 那么B系统对A用户的权限验证问题（B系统中没有A的用户信息，是否需要数据同步），

通过2个数据源链式访问验证用户，那么过后对于 一些操作（读取，删除）权限的验证 有没有什么好的策略进行延伸


也许这个问题已经不是单点登录问题？？

主要想知道有什么好的机制

1.  采用多个数据源的解决方案，实际上也有应用场合限定的。有些不是你们开发的子系统你就不一定能够直接访问他们的用户数据库。
2.  关于企业应用的话在原有系统上进行  SSO 集成的话，除了我上面说的方案外还可以使用 CAS 中的 LDAP 方式。 最典型的应用场景就是： 公司 某个OA系统，是cas的其中一个client应用，然后公司希望在 mail.compay.com 公司邮箱下的所用用户都能登录OA系统，并且在mail 中登录后，可以直接切换到 oA 中，不需要重新登录。
3.至于你说的关于 读取删除之类的权限验证，确实与 SSO 没什么关系了，SSO 只管对 验证通过的用户颁发访问指定应用系统的ticket。其它权限之类由子应用系统处理。

39 楼 denger 2011-04-26  

fandayrockworld 写道

denger 写道

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 如果默默注册？

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

但是对于那种已经做好了N个系统、已经用了好长时间，忽然有一天想做单点登录，这种情况的话应该是 登录表都分到多个应用系统中 吧。
当然，如果N个系统都还没做就已经考虑到要实现单点登录的话，最好把用户表统一弄到一块。

是的，你说的这种问题我也遇到过，采用过以下两种方式解决过。
1. 可以采取用户映射方式。 但是仍然建立一个统一的用户数据表 及用户数据映射表来适应以前的系统，对于以后新加入的应用系统，仍然采用统一的用户数据表。
2. 合并用户数据，仍然采用第一种方式，当然如果存在同名的用户就另当别论了。～

38 楼 denger 2011-04-26  

fandayrockworld 写道

denger 写道

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 如果默默注册？

把信息都放到CAS的ticket里不行吗？

最好不这样，这样也太不专业和安全了。 人家的 ticket 是在 url 并且是 get 方式进行转送的。

所以我觉得最好的方式还是第一种，当然，实际第一种方式仍然可以改进的。

37 楼 fandayrockworld 2011-04-26  

denger 写道

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 如果默默注册？

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

但是对于那种已经做好了N个系统、已经用了好长时间，忽然有一天想做单点登录的情况的话， 登录表都分到多个应用系统中 吧。
当然，如果N个系统都还没做就已经考虑到要实现单点登录的话，最好把用户表统一弄到一块。

36 楼 fandayrockworld 2011-04-26  

denger 写道

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 如果默默注册？

把信息都放到CAS的ticket里不行吗？

35 楼 denger 2011-04-26  

fandayrockworld 写道

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协议调用？

是的。可以看看 http://www.infoq.com/cn/articles/rest-introduction