I'm suggesting that you treat the applet as if it were an application that has nothing to do with the web (like the desktop applications you mentioned, or like an IMAP server).
CAS proxy authentication was designed in part for such non-web applications. A web-mail program can, for example, authenticate users via CAS and then proxy this authentication to its "back-end" (e.g., IMAP) server using a proxy ticket. I suggest you do the same thing to allow an applet or desktop application to authenticate users: an HTTP server authenticates the user via CAS, obtains a proxy ticket from CAS, and then sends this ticket to the applet or application; the applet or application then checks this proxy ticket with CAS. Of course, this might not be the end of the story. You might additionally want the applet or application to authenticate to some content provider. (CAS would support this too; you can have multiple "tiers" of proxies.) I'm just discussing the first step -- how the applet determines the authenticity of a user. Shawn On Sun, 18 Jun 2006, Ingeneur wrote: > I am sorry, but I didnt get the second part correct!! Should I CASify > the applet's content provider?? Is that what a back-end app is ? Sorry > about my ignorance. > > On 6/18/06, Shawn Bayern <[EMAIL PROTECTED]> wrote: > > 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 > > > > > -- > 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
