Inter-application access

[Phil Stone]

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
>