1 Reply Latest reply on Nov 1, 2011 3:45 PM by James C

    Multiple Wars Sharing a Login Page

    James C Newbie

      Greetings all.

       

      I am currently using JBoss 6.1.0.Final

       

      I have several EARs each with their own WAR.  I am using the standard single sign on valve and form based authentication.

       

      The intent is for the user to go to a WAR's URL, be redirected to a login page, and then be sent back to their original page.  I would like it if all the WAR's could share a login page.

       

      Problem one occurs because I can not access a page outside of the war.  For example given these three domains

       

      /main

      /sub1

       

      The WAR associated with the /sub1 domain can not point to /main/login.jsp.  If I attempt it then I simply go to the page /sub1/main/login.jsp.

       

      I have a attempted a simple redirect page in /sub1 pointing to the login page in /main.  The problem with that is that after authenticating the SSO Valve forwards you to the last page which was the redirect to the login page causing what would be a nasty loop but results in the error "Invalid direct reference to form login page"

       

      Is there any way to pass along the actual original request url?

       

      What are some solutions to this problem other than including the login fucntionality in every war?

       

      I don't mind making custom valves or filters if necessary however, I have read about failed attempts to add a filter for j_security_check.

       

      The only thing I have on the table right now is to extend the FormAuthenticator and add in the functionality to pass in an original url in a parameter but I would think that this is not an uncommon problem with a better solutions.

       

      Any suggestions and/or advice welcome.


      Let me know if I need to provide more information or elaborate on anything.

       

      Thanks in advance.

        • 1. Re: Multiple Wars Sharing a Login Page
          James C Newbie

          This was the solution I went with if anyone later is interested.

           

          I extended the standard FormAuthenticator class and overrode the methods forwardToLoginPage and forwardToErrorPage.  These two methods use a RequestDispatcher in order to forward the request to the login page.  The problem is that it forwards the page within the current context and does not go outside of the context.  I discovered that you can forward outside of the current context by using the ServletContext.getContext(String uri) method to acquire the context that the login page resides in.  So I simply changed

           

           

          {code}

          RequestDispatcher disp = this.context.getServletContext().getRequestDispatcher(config.getLoginPage());

          {code}

           

          to

           

          {code}

          RequestDispatcher disp = this.context.getServletContext()

                          .getContext("/myLoginPageContext")

                          .getRequestDispatcher("/myLoginPage.jsp");

          {code}

           

           

          Two small things to note.  First is that anything linked to inside myLoginPage.jsp must contain the whole path not just the name.  For example

           

           

          {code:xml}<img src="/myLoginPageContext/logo.jpg" />{code}

           

          Second, is that if you do not include an entry for form-login-page and form-error-page in the web.xml then the FormAuthenticator will crash while attempting to compare the requestUri with login page's uri.  I didn't want to bother putting the path in every web.xml or worry about changing them all later in the event the path to the login page changes so I overrode the Invoke method inside my new FormAuthenticator set the loginConfig to the paths I already defined in the class and used in the previously mentioned methods.

           

          Well that was it.  If anyone comes across this and sees an immediate problem in security by doing this please let me know.  If not then maybe it'll help someone else trying to do this later.