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

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

楼主提得问题其实和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责任范围，所以只能自己想办法

你妹,还不睡觉.

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

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

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

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

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


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

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

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

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

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

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

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