Andrew, Thanks for the informative answer. I understand now how one application can authenticate to another via proxy, but my situation is complicated by the fact that both A1 and A2 (to use your example names) are public-facing; I can't be sure which will be accessed first.
If I understand what you've described correctly, the proxy-granting application must be accessed *before* any other application seeking authentication through it. I think (unfortunately!) that means I'll need to write a completely new "entry" wrapper application which intercepts all requests, and acts as proxy-granter to all the other applications. Does that sound correct? Phil Andrew Petro wrote: > Phil, > > [ > > other web apps in the suite need to access this CAS-ified app. > via http requests. Is this even possible? > > ] > > Yes, very. > > [ > > I don't think proxying applies in this situation > (please correct me if I'm wrong). > > ] > > Proxying may apply, depending on whether you want to involve an end user > SSO authentication. > > > Suppose we have end-user-facing application A1 and a second application > A2 which for our purposes is non-end-user-facing, rather its purpose is > to expose and service HTTP endpoints. In these respects A1 is a "tier > one application" and A2 is a "tier two application". Suppose further > that A1 will need to actually make these HTTP requests of A2. > > Suppose there is an end user U. > > Proxy CAS accomplishes the following: > > End user U authenticates to A1 via CAS, in the way you have apparently > already implemented. A1 needs to access HTTP endpoints provided by A2 > in order to service U's interactions with A1. A1 can aquire a Proxy > Granting Ticket (PGT) which authenticates A1 in the context of a session > with U. A1 uses its PGT to acquire a Proxy Ticket (PT, sometimes called > a "Proxy Service Ticket") and presents that PT on its HTTP request to > A2. A2 validates the PT. When it does so, it obtains from CAS the > assertion that 1) the PT was vended to A1 (A1 itself is authenticated) > and 2) the PT was vended in the context of a single-sign-on session with > U (U's authentication is being proxied, and A1 could not have acquired > this PT but for U having authenticated with A1 in the context of a > still-live end-user SSO session). > > In this way A1 can authenticate itself *and its end user context* to A2 > in making HTTP requests of A2. > > [ > > I guess the question boils down to > this: can distinct web apps share a common authentication and conduct > trusted http transactions with each other? > > ] > > Yes, they can. > > The above discussed using CAS proxy tickets to do this. Proxy tickets > authenticate applications to one another in the context of end user > single-sign-on sessions. > > However, if you wish merely to authenticate A1 to A2, outside the > context of any particular end user SSO session, you can still use CAS to > accomplish this in a manner similar to what Rutgers accomplishes with > WOLP (maybe prevail upon Scott Battaglia to discuss that) or you could > leave CAS out entirely. How would you do this without CAS? Shared > secrets or, I would argue preferably, SSL certificates accomplishing > *both* requestor and server authentication via HTTPS. > > Andrew > > > >> Hello, >> >> I have been tasked with CAS-ifying a suite of cooperating web >> applications. I started out by wrapping CAS around one of the web apps, >> and that is working quite well (I'm using the JA-SIG Java client). >> >> However, other web apps in the suite need to access this CAS-ified app. >> via http requests. Is this even possible? How can a CAS-wrapped web >> app. authenticate an external one sending it requests, as they are in >> two separate contexts? I don't think proxying applies in this situation >> (please correct me if I'm wrong). I guess the question boils down to >> this: can distinct web apps share a common authentication and conduct >> trusted http transactions with each other? >> >> >> Phil Stone >> UC Davis >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
