[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 Phil Stone wrote: 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: |
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
