1 2 Previous Next 15 Replies Latest reply on Feb 5, 2008 7:14 AM by Werner Kolov

    HTTPS redirection

    Vladimir Kovalyuk Apprentice

      My login.page.xml looks like

      <?xml version="1.0" encoding="UTF-8"?>
      <page xmlns="http://jboss.com/products/seam/pages"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.0.xsd"
       scheme="https">
      ...
      </page>
      


      when brouser loads http://host:8080/someurl.seam it is redirected to https://host:8080/login.seam

      it is possible to point somewhere that the https port is 8443 or it is a bug?


        • 1. Re: HTTPS redirection
          Shane Bryzak Master

          In components.xml:

          <navigation:pages http-port="8080" https-port="8443"/>


          • 2. Re: HTTPS redirection
            Richard Stanford Newbie

            Does this process work with external SSL decoding?

            We need to be able to mark certain pages as requiring SSL (or at least make sure that links to the contain https:// on them); but we're setting up external SSL decoders so the Seam app will never actually see any SSL traffic.

            Is there some kind of best-practice in this situation?

            • 3. Re: HTTPS redirection
              Richard Stanford Newbie

              In fact, it would appear according to this JIRA that there is a problem - any thoughts as to a solution? Surely we're not the only volume-oriented business planning to move forward in this way - I'd like to think its a solved problem :-)

              http://jira.jboss.com/jira/browse/JBSEAM-1024

              • 4. Re: HTTPS redirection
                Shane Bryzak Master

                If you're implementing SSL at the web server level (e.g. Apach HTTPD) then don't set your scheme to HTTPS in Seam. To answer the other question, there is no way that Seam can know that a request coming from the web server through a connector was originally SSL-encoded.

                • 5. Re: HTTPS redirection
                  Richard Stanford Newbie

                  Actually, what would be great (but not helpful for us at the moment) would be if the Pages.getRequestUrl() method was actually overridable. That way, for those of us with offloaded SSL, we could simply check a header (or whatever) and report back, "Yes, this was sent as SSL." That would allow the use of the "scheme=" attribute in pages.xml, which is really great.

                  Without using scheme=, its a bit of a pain in fact.

                  I'm now looking at trying to do a filter upstream of the Seam filter (sadly not an area I'm very familiar with) to change the HttpServletRequest URL (conditionally). That seems to be pretty risky to me, but I'm thinking its our only hope if we want SSL offloading /and/ proper http->https redirection...

                  As always, advice is welcome. I suppose that the other possibility would be to build a hacked version of Seam, but that's not a direction I really want to head...

                  • 6. Re: HTTPS redirection
                    Ronald van Kuijk Master

                     

                    "shane.bryzak@jboss.com" wrote:
                    To answer the other question, there is no way that Seam can know that a request coming from the web server through a connector was originally SSL-encoded.


                    Can't you just set a http header in apache with the correct module that can be parsed by seam?

                    • 7. Re: HTTPS redirection
                      Richard Stanford Newbie

                      Yes, if we didn't mind running on a custom version of Seam. The ideal solution here would be for Seam to allow us to override their functionality, just as we do for user authentication... that way there wouldn't be any problem, most people could continue to use the "look-for-https-string" method, and anyone with offloading could add their own checks.

                      • 8. Re: HTTPS redirection
                        Matt Drees Master

                         

                        I'm now looking at trying to do a filter upstream of the Seam filter (sadly not an area I'm very familiar with) to change the HttpServletRequest URL (conditionally).


                        This is what we're planning to do. I haven't tested it yet (don't have an ssl cert set up yet), but I think it should work. I'll report back if it doesn't.

                        We use BIG-IP for loadbalancing and ssl decryption. For ssl requests, we've configured it to add a specific request header. I haven't tested this, but I think we only need to override Request.getScheme(), and not Request.getRequestURL().

                        
                        @Name("bigIpSslFilter")
                        @Scope(ScopeType.APPLICATION)
                        @BypassInterceptors
                        @org.jboss.seam.annotations.web.Filter
                        public class BigIpSslFilter implements Filter {
                        
                         public void destroy() {
                         }
                        
                         public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain filterChain) throws IOException, ServletException {
                         if (request instanceof HttpServletRequest) {
                         filterChain.doFilter(new BigIpSslRequest((HttpServletRequest) request), response);
                         } else {
                         filterChain.doFilter(request, response);
                         }
                         }
                        
                         public void init(FilterConfig filterConfig) throws ServletException {
                         }
                        
                         public static class BigIpSslRequest extends HttpServletRequestWrapper {
                        
                         public BigIpSslRequest(HttpServletRequest request) {
                         super(request);
                         }
                        
                         @Override
                         public String getScheme() {
                         String forwardedScheme = getRequest().getHeader("HTTP_X_FORWARDED_PROTO");
                         if (forwardedScheme != null && forwardedScheme.equals("https")) {
                         return "https";
                         }
                         return super.getScheme();
                         }
                        
                         @Override
                         public HttpServletRequest getRequest() {
                         return (HttpServletRequest) super.getRequest();
                         }
                         }
                        }
                        


                        (btw, it's the same header that rails looks for to determine proxied https requests, since we also have some rails apps)

                        • 9. Re: HTTPS redirection
                          Devon Hillard Novice

                          Why not use SSL between the BigIPs and Jboss? The overhead is pretty small on modern hardware, plus it's generally good form to encrypt the user traffic the whole way through your first layer at least.

                          We used BigIPs in this very way. they provided the SSL endpoints, inspected the incoming requests using F5's security modules, did a few other things, and then reached back to the servers via SSL using internally signed certs, for the connection between DMZ1 and DMZ2.

                          • 10. Re: HTTPS redirection
                            Matt Drees Master

                            I suppose that makes some sense. But for us, it's probably more trouble than it's worth.

                            • 11. Re: HTTPS redirection
                              Pete Muir Master

                               

                              "rjstanford" wrote:
                              Actually, what would be great (but not helpful for us at the moment) would be if the Pages.getRequestUrl() method was actually overridable. That way, for those of us with offloaded SSL, we could simply check a header (or whatever) and report back, "Yes, this was sent as SSL." That would allow the use of the "scheme=" attribute in pages.xml, which is really great.


                              Add a feature request for a way to customise SSL detection, this seems like a reasonable thing to want to do. I don't know how Shane will decide to implement it though ;)

                              • 12. Re: HTTPS redirection
                                Shane Bryzak Master

                                I think I like Matt's idea of overriding HttpServletRequest.getScheme() in a filter. In my opinion, that would be the preferred method.

                                • 13. Re: HTTPS redirection
                                  Ronald van Kuijk Master

                                  getScheme does not work on all appservers with a reverse proxy in front of it (afaik). So I tend to vote for pete's proposal to make it customizable, where the getScheme is the default impl.

                                  • 14. Re: HTTPS redirection
                                    Devon Hillard Novice

                                    You could also use RewriteCond and RewriteRule on the apache instances (if you're using apache with ssl after the BigIP, otherwise I think the F5 can be configured to do this as well) to enforce this. Obviously it would be nice to have this handled with in the application, but if you need a quick fix that's easier than re-encrypting the connection to the JBoss server that might work.

                                    1 2 Previous Next