Thanks again, Andrew! Is there any example code for configuring the JA-SIG Java CAS Client for proxying? The home page for that client says that docs and examples are included with the client download, but I sure don't see any. I have found some examples using the Yale client, but none for the JA-SIG client.
Phil Andrew Petro wrote: > [ > 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? > ] > > Doesn't sound necessary to me, but I may be misunderstanding. > > And hey, if you decide you need a portal to front your applications, > I've certainly got one in mind with particularly good CAS integration... > > That A2 was exclusively a tier-two application was a simplification > for purposes of the example. > > There's nothing that prevents both A1 and A2 from including > end-user-facing URLs performing tier-one CAS service authentication. > End users can experience single sign on, such that whatever order they > visit the applications, they need log in via CAS only once. > > There's further nothing that prevents both A1 and A2 from > proxy-authenticating to service-facing URLs exposed by the other, > accessed in the course of servicing end-user web requests. > > The user might first access A1, and in the course of servicing the web > request, A1 might proxy authentication to A2 in order to obtain or > push, in a secure and authenticated way, relevant data. On the other > hand, the user might first access A2, and in the course of servicing > the web request, A2 might proxy authentication to A1 in order to > obtain or push, in a secure and authenticated way, relevant data. > > An application looking to proxy to another application must first be > logged into by an end user, in order to establish an SSO context, to > have an end user authentication to proxy. CAS proxy ticket technology > as normally implemented does not address the use case of an > application authenticating to another application out of the blue, > outside the context of any particular user's SSO session. This is a > feature of the CAS protocol. A developer building a library account > summary portlet that obtains library account information via a > CASified http request to a library feed, for instance, is not able to > *arbitrarily* query the backing service; he is only able to query the > backing service in the context of an end user having actually logged > into the portlet (portal, really). This helps control data release > and protect end user privacy. > > However, at least Rutgers has leveraged CAS to perform > application-to-application authentication. The simple version of this > story is that it's accomplished by modeling applications as themselves > end users able to authenticate to CAS and obtain (non-proxy) service > tickets. Applications taking the role of the end-user in the CAS > protocol. This can be done, and has been done; I would argue that for > this use case other solutions, such as client-side SSL certificates, > might do just as well. > > Andrew > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
