Hi, The trust across CAS server setup in the cited paper do assume a common identity source. You may have caught this already, but there is a note on the deployment diagram that if this is not shared (scenario you seem to be describing), you'd need a custom principal resolver, in addition to the CAS configuration and apache mod_auth_cas hooks. Sharing the user repository (as you seem to suggest is possible in your last post), then trying to work out the configuration for sharing across CAS servers seems like the path of least resistance for this shared solution. Regarding reference resources, it would be helpful to have the step-by-step configuration to go along with the text in the paper.
Brian On Wed, Dec 7, 2011 at 10:49 AM, <[email protected]> wrote: > Hi Marvin, > Did you get some time to read Field's article? > Or, can you or somebody point me to some resources so that I can learn how > to set up SSO across different domains sharing a common user database? > > Cheers, > s400t > > > > --- On *Tue, 2011/12/6, s400t <[email protected]>* wrote: > > > I thought I was in wrong forum, so I jumped the ship :) > (Marvin, please comment here when you can. Thanks.) > //------------------------------ > > I was trying to learn how to trust a remote CAS server's authentication so > that once authenticated through a local CAS, the user does not need to see > that log-in screen again. > > Then I found J. Field's excellent paper and read it and I understood it a > little better. (I have yet to do the implementation.) > > But I do not still have a clear picture what happens at the non-local > (remote) CAS server. Let me explain below what I learnt from Field's > article. > > > 1. A locally authenticated user accesses a remote, CAS-protected > application. > > 2. Remote application checks with remote CAS. > > 3. Remote CAS has an Apache front end with mod_auth_cas set up, and there > is something in the URL header ("REMOTE"?) that makes the remote CAS > forward the request to the origin, that is, the remote CAS asks the local > CAS for a ticket. > > 4. Local CAS issues a service ticket (ST) to remote CAS. The key here is > to treat remote CAS server as an application. So for the local CAS, it is > just like issuing an ST for an "application". > > 5. Upon seeing that the request has an ST, the remote CAS then issues a > ticket granting cookie (TGC), which is returned to the browser, and also > issues an ST good for remote application. > > 6. Remote application is happy because for it, the authentication came > form the their "local" CAS, in which they trust. Hence, SSO is realized (no > second log in necessary.) > > Question: > At no. 5 above, how does the remote CAS know how to trust the visitor? The > visitor only has an ST (not for any particular application, but for "remote > CAS application" as a whole), and perhaps user ID? Validation against the > remote database should not be possible because the request string does not > contain password. > > Or the remote location's user repository won't be consulted at all in this > scheme? > > What are the necessary and sufficient conditons for the remote CAS to > issue ST and TGC for visitors who are authenticated at other location(s)? > > (In my case, both the local and the remote domains have exact same copy of > user repository.) > > Thank you for taking time to read and for your comments. > > Cheers. > > > //----- > J. Field's article: > > > http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CBsQFjAA&url=https%3A%2F%2Fwiki.jasig.org%2Fdownload%2Fattachments%2F48596744%2FHow%2Bto%2BTrust%2BAnother%2BCAS%2BServer.pdf%3Fversion%3D1%26modificationDate%3D1321479461428&ei=0e7cTtiqGOKHmQXd4OnTCw&usg=AFQjCNH5FlhDZHU_oHBOCj-rg_WtLMT4IA > > or you can google for "How to Trust Another CAS Server" > > --o0o-- > > > -- > You are currently subscribed to > [email protected]<http://jp.mc1000.mail.yahoo.co.jp/mc/[email protected]>as: > [email protected]<http://jp.mc1000.mail.yahoo.co.jp/mc/[email protected]> > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
