Hello, CAS is an authentication mechanism wherein the Central Authentication Service server serves as the "trusted intermediary" brokering authentication between participants. Participants need not trust one another so long as they all trust the CAS server.
End users and their web browsers must trust the CAS server (otherwise the user shouldn't feel comfortable typing in her password!) They must also trust the channel of communication between one another. The standard way for securing the channel between browser and website is SSL. So it is obligatory that your CAS server be accessed by the end user over SSL. The "client application", the non-CAS web application that the user's really trying to authenticate to, must also trust the CAS server (otherwise it shouldn't care who the CAS server says the user is). And it must trust the channel whereby it communicates with the CAS server. The standard way for securing the channel over which web requests are fulfilled (and CAS services are really lightweight XML over HTTP "web services) is SSL. So it is obligatory that your CAS server offer the ticket validation services over SSL. SSL is a public key encryption technology. If you pay a good chuck of money for a "real" commercial SSL certificate, then it will be signed by a certifying authority that "everyone" trusts implicitly and it just works. For your real production CAS server it makes a lot of sense to throw money at this problem and buy such an SSL certificate, with the resulting improved user factors both for end users and applications using CAS. For smaller CAS deployments and certainly in development it makes a lot of sense to use a "self-signed" certificate. Since self-signed SSL certificates are essentially just made up on the fly, it is necessary to distribute the corresponding public key. Your self-signed SSL cert is only meaningful to me inasmuch as I have by a secure mechanism already received the corresponding public key. For Java web applications, installing that public key into the JVM keystore of the client application will result in the Java CAS client in the client application being able to verify the security of the channel (SSL) between it and the CAS server and so it will be able to validate service tickets. That was a long way of saying "Yes, it is necessary to import the public key portion SSL certificate into the JVM keystore of any client Java web applications using your CAS server, unless your SSL certificate is implicitly trusted by virtue of its being expensive." And of course, whether you have a self signed certificate or a commercial certificate, you will need to install it into your Tomcat keystore for your CAS server so that it can offer the CAS web application over SSL, if Tomcat is going to be your SSL endpoint. (Apache, or some expensive hardware box in front of your CAS server, might instead be your SSL endpoint for your CAS server.) This help any? Would it help if something very much like the above were pasted atop the CAS documentation page on SSL considerations? http://www.ja-sig.org/wiki/display/CAS/Solving+SSL+issues Andrew > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of kike velez > Sent: Saturday, September 23, 2006 3:50 PM > To: [email protected] > Subject: SSL :Certificates to JVM keystore? > > Hello > > I looking for this question on the archive but i don´t have this issue to > clear. > > Its obligatory to import the ssl certificates to de jvm keystore? > if the answer is yes Why? > > I see in the Tomcat documentation and i don´t see nothing about it. > > Thanks in advance _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
