I would think the easiest way to CASify a Java applet would be to have the page that vends it authenticate the user and then proxy this authentication to the applet. The applet could then simply validate the proxy ticket it receives from its server; you could even send this ticket as an applet-initialization parameter (to avoid the need for continuing communication between the applet and the server over RMI or JAX-RPC or whatever people use these days).
At any rate, you're not going to be able to CASify the applet as if it were a first-tier web page without wrenching CAS's protocol beyond the cases for which it was designed. Think of the applet as if it were a back-end (non-Web) application, like a mail server, and that will lead you to the most straightforward solutions. Shawn On Sat, 17 Jun 2006, Andrew Petro wrote: > I don't know much about applets. Here's my stab at a reply anyway: > > As I understand it, a Java applet is strongly associated with some > authoritative website from which it is loaded. > > So make the user CAS authenticate to that website and then have that website > communicate the authenticated user (perhaps cryptographically signing this > assertion?) to the applet. This is pretty easy as a gateway to get the > applet in the first place (and then just deliver an > authentication-provisioned applet.) > > If you really want the user to start from the applet and "get > authenticated", then produce a URL in the applet to the website with an > identifying session key, and then the website can require CAS authentication > and provide a service that the applet call with the key to see who's > authenticated for that key. > > However, providing any authentication to a Java applet is a tough way to go. > The code is running on the end user's computer. He can do arbitrarily > clever things like replace the local JVM with a compromised JVM. So more or > less whatever you come up with, there will be some way for the end user to > fake out the applet once received to believe he is someone he is not. > > However, if the applet in turn uses CAS proxy tickets to proxy > authentication to access whatever it is that it accesses, then security can > be restored inasmuch as it will not be possible to get valid proxy tickets > in the name of anyone other than the user who received the ST from which the > PGT was derived. You'll have to solve interesting problems to use proxy > tickets including what the proxy callback URL is going to be -- presumably > also a service provided by the website hosting the applet. > > In any case, I would strongly recommend against the applet accessing the CAS > TGT cookie directly. That cookie is intended to be only available to the > CAS server. No CAS-using services should ever see or touch that cookie, and > widening the scope of that cookie or making it visible over non-SSL'ed > connections seriously compromises the security of the CAS protocol. > > > Use case? What will your applet do? > > Andrew > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Ingeneur > > Sent: Saturday, June 17, 2006 6:27 AM > > To: Yale CAS mailing list > > Subject: casify applets > > > > Hi All, > > > > I need some starter ideas on how to casify a java applet. Is this > > possible at all?? I can have the page casified. Can I then try a > > URLConnection to the cas server to get the User Logged In?? Will the > > applet need to read the CAS cookie information?? > > > > Am I talking sense at all???? > > > > Thank You > > -- > > Regards, > > > > Abishek Goda > > http://www.geocities.com/abi_gt > > _______________________________________________ > > 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
