No problem, hope that it helps out! OH - proxyport=443 is important too, forgot to list that one earlier.
Overall, this has worked beautifully for us :) And it makes it MUCH simpler too because we now have one SSL cert to change in one place, instead of having to redo java keystores on all of the different Tomcat instances. The one thing that we've run into with doing things this way is that the first time you'd log into our campus portal from CAS, the browser would timeout and would eventually end up at the url https://my.millikin.edu:80/muportal/secure/ . However, if you'd try to go to the campus portal afterwards, it would go through fine. It turned out to be something I wouldn't have ever expected - the code in index.jsp that strips the ?ticket=.... stuff out of the URL after you log in: } else if ((!StringUtil.isNull(queryString)) && (queryString.indexOf("ticket") > -1)) { queryString = queryString.substring(0,queryString.indexOf("ticket")-1); response.sendRedirect("/muportal/secure/" + queryString); } But, after changing it to response.sendRedirect("https://"; + String.valueOf(request.getServerName()) + "/muportal/secure/" + queryString); it worked fine. (We have this code in there because otherwise the "?ticket=xxxxx" stuff messes with Google Analytics and JavaMelody.) Chris >>> Stephan Arts <[email protected]> 02/09/16 8:35 AM >>> Thanks, this appears to be a neat solution :-) Cheers, Stephan On Tue, Feb 9, 2016 at 2:59 PM, Christopher Myers <[email protected]> wrote: What we do is: internet(https) -> (https)load balancer(http) -> tomcat (http) Basically, the load balancer talks https to the internet and http to tomcat, doing the SSL offloading. This is what the connector in our server.xml file looks like: <Connector port="8080" protocol="HTTP/1.1" maxThreads="500" compression="on" URIEncoding="UTF-8" proxyPort="443" secure="true" scheme="https" SSLEnabled="false" /> the important parts are the secure=true and scheme=https parts. We're on CAS 4.0.x. Chris >>> Misagh Moayyed <[email protected]> 02/09/16 4:04 AM >>> The ssl warning is actually good test to demonstrate that something is broken and dysfunctional in your deployment. As Scott said, you will need to find a way to relay the SSL context back to the application server. The warning shows up only if that chain is broken. You’ll need to consult apache/tomcat.load balancer docs to see how to configure your containers. There is nothing in CAS that requires/enables you do this, other than the expectation that HTTPS is available by simply checking the request. (Which is the piece you can turn off, but should not since the problem is elsewhere) - Misagh On Feb 9, 2016, at 9:29 AM, Stephan Arts <[email protected]> wrote: My workaround was indeed to do this: internet -[HTTPS]> load-balancer -[HTTP]> apache -[HTTPS]> tomcat... I don't like it either, since it requires me fiddling around with the java keystore and self-signed certificates, which is an administrative overhead with no added value when it comes to security. I'd much rather have apache provide the X-Forwarded-Proto header set to HTTPS and instruct tomcat to tell cas 'every thing is fine, walk along'. Unfortunately, that does not work. (CAS 4.0.7) - Is there a way I can suppress the HTTPS warning? There really is no reason to encrypt the data going over the loopback device. Cheers, Stephan On Mon, Feb 8, 2016 at 6:55 PM, Scott Battaglia <[email protected]> wrote: If something is fronting CAS that is terminating SSL, you should be able to indicate to the servlet container hosting CAS that it really is a secure connection. Does that not work? (sorry I can't remember the specifics of it) On Mon, Feb 8, 2016 at 12:52 PM, Robert <[email protected]> wrote: Hi MisaghOn Monday, February 8, 2016 at 12:20:57 PM UTC-5, Misagh Moayyed wrote: On Feb 8, 2016, at 8:14 PM, Robert <[email protected]> wrote: Our current Production Setup For CAS3.x.x having SSL was not required to support Single Sign On. This was perfect as we have Reverse Proxy Servers fronting our Application Server farm and it took care of providing all TLS for our user facing interface. All handshake between the reverse-proxy server and JBOSS/ IBM WAS server farm was “as if” no SSL was in place. This also helped us immensely in terms of performance, as all SSL encryption/decryption was handled on our Reverse Proxy Servers. And helped cut cost for our clients in terms of maintaining and purchasing certificates to bare essential. All of that still true in CAS4. Now, we are trying to work with CAS4 We found out that it requires HTTPS or else Single Sign On just won’t work. HTTPS is always required by default. How you satisfy that requirement remains the same across all CAS versions. There are not considerations on the CAS side to dictate a particular form of container configuration. Can you help us understand as to how do we make this new solution work within our production sites? 1. Will this not force us to have certificates deployed on each and every Application Server? How do we make our clients understand the cost benefit of doing so when having Reverse Proxy Fronting was already taking care of this? 2. What happens where the server farms are running behind 3-Zone architecture? 3. What would be performance hit on Application Server when during peak load the server would also have to deal with TLS over and above the work that it is currently supposed to be handling? Can we turn off this HTTPS requirement to support SSO with CAS4? If so can you help us as to where to begin. You can enable SSO without HTTPS. This is of course a bad idea. Our situation has become very urgent, so we don't mind if we have to write Java code and change XML configuration. Thanks for your help. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
