Forum Discussion

Toni_5704's avatar
Icon for Nimbostratus rankNimbostratus
Oct 26, 2010

irules and j_security_check




Our security officer asked us to secure via SSL the user/password sent by our login page, and we would like to use the F5 to do this.




We are using the standard Jakarta Tomcat Form Login mecanism, where Tomcat redirect automatically the new user to a login page that sends the credentials to the /j_security_check embedded servlet.




So is it possible to secure via HTTPS just the login part on a Webapp ; Especially the j_security_check url transaction, then go back to normal HTTP ?






Note : I've found this similar post on the forum, but it doesn't give a iRules/F5 solution to this problem:






Any hints on how to do this would be greatly appreciated.











8 Replies

  • Couldn't you configure Tomcat to use HTTPS? Else, you could potentially use a stream profile and STREAM::expression based iRule to rewrite the form action from a local reference (HTTP) to an absolute reference with HTTPS. You'd also need to serve any content that the form action URL calls to avoid getting an insecure content warning on browsers.



    Here's the wiki page for the stream related events and commands:





    The STREAM::expression page has a few examples:





  • >Couldn't you configure Tomcat to use HTTPS?


    We would like to use the F5 because we need to secure a whole bunch of apps using different technologies. Most WebApp are using Tomcat/Jboss, but others are WebObjects or even C++.The F5 could secure the passwords transmission in a centralized manner.



    > to rewrite the form action from a local reference (HTTP) to an absolute reference with HTTPS



    then how do we go back to HTTP after the login as been done ?








  • Hi Toni,



    Here's an interesting article to check out on partial SSL encryption for web apps...





    You could use an iRule on the HTTPS virtual server which redirects any requests that you want served over HTTP back to HTTP.



  • Hey Aaron,



    Thanks for this precious feedback.



    After some digging, here is what we came with:



    A simple irule that would check the presence of a custom HTTP response header, say "CUSTOM_TRANSPORT_SECURED=true". If the header is in the response, redirect the user to HTTPS otherwise, use HTTP.



    Here is one scenario:



    1) The user ask for a page in HTTP


    2) The application adds the custom HTTP header to a given HTTP response (in our case the login form)


    2) An iRule would detect this HTTP HEADER and redirect the user the HTTPS


    3) The user fill the form and submit it back, still in HTTPS


    4) The next Response won't contain the custom header, thus the irule will switch back to HTTP.



    If this works, the data submited is protected, and we could use this technique to secure any part of the web application (login, critical forms,etc..), independently of the application server technology(java,C++,etc...)



    Before we start testing this, do you think it could be our solution ?



  • Hi Toni,



    I'm not sure it would be that easy. You probably wouldn't want to redirect the user after they make a request which the app responds to with content and the custom "HTTPS" header. You might want to rewrite the links in that response content to https. You could do this with a stream profile and STREAM::expression based iRule.



    If you wanted to test this, you could either use a test LTM, LTM VE or a test VS on a production LTM unit.



  • Hi Aaron,



    We solved this issue by going the way you proposed: Using 2 irules: one using STREAM::expression to rewrite the form action target the a https j_security_check hardcoded URL, the other to fall back to HTTP by default for any requests.






  • Hi Toni,



    That's great to hear. Can you post your current example for future reference?



    Thanks, Aaron
  • Hi Jerome,



    I always like the idea of using an iRule to enable/disable the stream filter. Without an iRule the filter is applied to request payloads as well as non-text responses. So you might get errant rewriting performed and will spend unnecessary cycles checking payloads that won't get rewritten. It's easy enough to create an iRule. You can check the STREAM::expression wiki page for examples: