CAS跨域问题

Yale CAS使用了Ticket Granting Cookie （简称TGC）去作为获取Service Ticket（简称ST）的凭据，这个TGC 是保存在客户端的cookie，即当第2次被其他CAS Client重定向的时候，CAS Server实际上已经从用户的Cookie中抓取到TGC，然后知道TGC对应的用户，因此避免了再次登录，如果CAS Server抓取不到TGC，则用户需要登陆。

CAS能够做abc.com和xyz.com的sso，因为CAS Server缓存了所有的ticket，所以Client无需共享cookies。
============================================================
CAS 如何实现 SSO
当我们的 Web 时代还处于初级阶段的时候， SSO 是通过共享 cookies 来实现，比如，下面三个域名要做 SSO ： http://www.blogjava.net http://www.matrix.org.cn http://www.csdn.net 如果通过 CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射， http://blogjava.cas.org http://matrix.cas.org http://csdn.cas.org 因为是同一个域，所以每个站点都能够共享基于 cas.org 的 cookies 。这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。[color=blue] CAS 可以很简单的实现跨域的 SSO ，因为，单点被控制在 CAS Server ，用户最有价值的 TGC-Cookie 只是跟 CAS Server 相关， CAS Server 就只有一个，因此，解决了 cookies 不能跨域的问题。[/color]============================================================
上网搜了一下国外CAS论坛相关的贴子，发现这个已经被CAS项目的作者讨论过了。
From: Thung, Peter C CIV SPAWAR SSC PAC, 56340 <peter.thung@...>
Subject: CAs and Single Institution versues cross domain institutions...
Newsgroups: gmane.comp.java.jasig.cas.user
Date: 2009-02-09 20:12:44 GMT (5 weeks, 6 hours and 10 minutes ago)


I just wanted to confirm with the group:
based on this FAQ, that
CAS is a Single Institution SSO solution.

So if we have web applications running in multiple domains federated across a WAN,
that CAS will not work for us and we will need something like Shibboleth.

-Peter
******************************************************************
============================================================
reply 1:
From: [color=blue]Scott Battaglia [/color]<scott.battaglia@...>
Subject: Re: CAs and Single Institution versues cross domain institutions...
Newsgroups: gmane.comp.java.jasig.cas.user
Date: 2009-02-09 21:13:52 GMT (5 weeks, 5 hours and 10 minutes ago)


[color=blue]If you merely have applications that exist on multiple domains, then CAS 3 will suffice. [/color] If you need to authenticate multiple sets of users who's authoritative source are different companies/institutions/etc. then you should look at at something that does federation such as Shibboleth or Ping (CAS4 will do it when it comes out also).
============================================================
reply 2:
From: Andrew Petro <apetro@...>
Subject: cross-domain versus cross-institution authentication
Newsgroups: gmane.comp.java.jasig.cas.user
Date: 2009-02-09 21:17:52 GMT (5 weeks, 5 hours and 5 minutes ago)

I agree with Scott's response, but having taken the time to write this
longer response, I've gotta send it. :) ...

Peter,

CAS is primarily a web authentication solution for use at a single
institution at a time. For instance, JASIG has a CAS server up at

https://www.ja-sig.org/cas/

JASIG uses this CAS instance to authenticate JASIGers to e.g. the
HyperContent content management system for editing the JASIG website,
which is blissfully being replaced with Drupal, but that's another story.

JASIG configures this JASIG instance of the CAS server to authenticate
JASIG users against a JASIG-run user credential store. (Here it happens
to be a database of Jira users, but the point is that it's a store
selected and maintained by JASIG.) JASIG's CAS instance is for the
purpose of authenticating JASIG users.

However, there's nothing tied up in domains about this. There's nothing
technically stopping me from CASifying http://www.unicon.net/ (which
blissfully already runs Drupal) such that users could use JASIG CAS to
log in rather than using Unicon's local account store. Policy might
stop me -- CAS can be configured to register which services may use it,
etc., but there's no technical requirement that applications to which
users authenticate via https://www.ja-sig.org/cas/ share a domain or
anything else with https://www.ja-sig.org/cas/ . [color=blue] Unlike some other SSO
solutions, CAS does *not* rely on applications making use of CAS being
able to see cookies CAS sets.[/color]
The federation that Shibboleth and use of Shibboleth via federations
like InCommon buys you is the ability to federate authentication and
account management. If Unicon and JASIG were both using Shibboleth and
were members of a federation facilitating the exchange and configuration
of policy, then Unicon users could authenticate via a Unicon IdP to
services offered outside Unicon. I could log in via Unicon's IdP to
edit the JASIG website, and not bother with setting up a JASIG local
account and remembering another password. That's what's meant by
federation.

Hope this proves helpful.

Best wishes,

Andrew