4 Replies Latest reply on Jun 15, 2017 4:40 PM by koller.michael81

    StickySessionCookie with mod_cluster 1.3.1 + Wildlfly10 + Single Sign On in Undertow possible?

    koller.michael81

      Hello Guy's

       

      I messed up with a configuration "Problem"

       

      Setup

      - Apache 2.4.6 with jboss_modcluster 1.3.1 (builded on centos7)

      - AppServer 1 Widlfly 10.0.1 with webapp1 and webapp2

      - AppServer 2 Widlfly 10.0.1 with webapp1 and webapp2

       

      I sucessfully setup Single Sign On (trouhg the undertow) so i can login on appserver1/webapp1 and with the next request (iframe call) to appserver1/webapp2 the Credentials are shared and everything ist working (Same on direct calls )

       

      Now i try to connect trough the "loadbalancer". When i connect to my webapp1 all subrequest are routed correct to the same server the first request are started (ex. appserver1/webapp1/push ). Now i start an action (iframe with emmbeded viewer relativ) to webapp2. Now the "Sticky" will not work (the JSESSIONID is not set but the JSESSIONIDSSO is set) and the Mod-Cluster send me to Appserver 2, where my credentials are not know.

       

      I can not change the Deployment, an Session replication is not an option so i tried to change the "stickySessionCookie" for the modcluster system.

       

      My mod-cluster manager always print

      balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 1 Timeout: 0 maxAttempts: 1

       

      So i tried to change the cookie to JSESSIONIDSSO but i find no way to change that "attribute"

       

      - Standalone-xml have no "attribute" for that

      - mod-cluster.conf changes did not solve the problem

      - undertow core patches try (Balancer.java and some stuff) had no effect (just a try)

       

      Somebody have a tipp or a hint (maybe my goal is not reachable with that standard setup, an i must do it trough "standar mod_proxy_balancer")

       

      Full-Snippet

      mod_cluster.conf

      Listen 6666

       

      <IfModule manager_module>

        <VirtualHost xxxx:80>   

          <Location /mcm>

            SetHandler mod_cluster-manager          

            #Allow from All

            Require all granted

          </Location>

        </VirtualHost>

       

        <VirtualHost xxxx:6666>

          <Directory />

            Order deny,allow    

            #Allow from All

            Require all granted

          </Directory>

          ServerAdvertise off

          EnableMCPMReceive

        </VirtualHost>

      </IfModule>

       

      Standalone.xml

      <server name="wildfly-node1" xmlns="urn:jboss:domain:4.0">

       

      <!-- Extension -->

      <extensions>

          <extension module="org.jboss.as.modcluster"/>

       

      <!-- Modcluster -->

      <subsystem xmlns="urn:jboss:domain:modcluster:2.0">

          <mod-cluster-config proxies="mcm-prox1" connector="ajp">

              <dynamic-load-provider>

                  <load-metric type="cpu"/>

              </dynamic-load-provider>

          </mod-cluster-config>

      </subsystem>

       

      <!-- ajp-Listener -->

      <subsystem xmlns="urn:jboss:domain:undertow:3.0">

                  <buffer-cache name="default"/>

                  <server name="default-server">

                      <ajp-listener name="ajp" socket-binding="ajp"/> <!-- <------ ajp-Listener -->

                      <http-listener name="default" socket-binding="http" redirect-socket="https"/>

                      <host name="default-host" alias="localhost">

                          <location name="/" handler="welcome-content"/>

                          <filter-ref name="server-header"/>

                          <filter-ref name="x-powered-by-header"/>

                          <single-sign-on/>

                      </host>

                  </server>

      <!-- ...... -->

       

      <!-- Anpassungen an den Sockets -->

      <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

              <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>

              <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>

              <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>            <!-- ajp Port-->

              <socket-binding name="http" port="${jboss.http.port:8080}"/>

              <socket-binding name="https" port="${jboss.https.port:443}"/>

              <socket-binding name="txn-recovery-environment" port="4712"/>

              <socket-binding name="txn-status-manager" port="4713"/>      

              <outbound-socket-binding name="mail-smtp">

                  <remote-destination host="localhost" port="25"/>

              </outbound-socket-binding>

              <outbound-socket-binding name="mcm-prox1">                             <!-- Outbound Socket-->

                  <remote-destination host="xxxxx" port="6666"/>

              </outbound-socket-binding>

      </socket-binding-group>

        • 1. Re: StickySessionCookie with mod_cluster 1.3.1 + Wildlfly10 + Single Sign On in Undertow possible?
          pferraro

          This is not achievable without using distributed web sessions.  The problem is, sticky sessions rely on routing information appended to the JSESSIONID, not the JSESSIONSSOID.  Consequently, when a requests arrives for the second web application (including the JSESSIONSSOID cookie associated with the host), the load balancer doesn't know to route the request to any particular node, a request for the second web application can arrive on a different node than the one that handled the requests for the first web application.  The only way to handle this is to use a <distributable/> web application.

           

          You mentioned, "I can not change the Deployment, an Session replication is not an option".  Why not?

          • 2. Re: StickySessionCookie with mod_cluster 1.3.1 + Wildlfly10 + Single Sign On in Undertow possible?
            koller.michael81

            Hi Paul

             

            The JSESSIONID is only the "default" value in the subsystem (undertow/balancer and so on)

             

            With Jboss (Tomcat) i can change the "Sticky"-Session Property trough a system property (org.apacher.cataline.JSESSIONID xxx).

             

            In the undertow-core, there are the setter (Balancer.java and BalancerBuilder.java) for the StickySessionCokieName (default is JSESSIONID) cause many Application have other Cookies (sepcial for domain tracking and so on). But i could not get my patches working, cause the System is really hard do debug/track to change that "default"-Value (im still in Progress). The standalone.xml does not provide a attribute to propapgate that value (just for "force" and "remove" ...)

             

            I can manage a simpe HTTP-System with mod_balancer_proxy where i can set the sticky-cookie-name to balance (but i will use mod_cluster if it is possible in a way, cause we use a complex Stack and the jboss_modcluster can easy handel that stuff) so my idea is to change the stikysessioncokiename to the JSESSIONIDSSO in the "mod_cluster_system"

             

            We have a complex distributed System with legacy-security-stuff (3-parties) and we cannot replicate that stuff (no way, we tried a lot). So we must do some "special"-Things like the "Sticky-SSO-Session". I know that's strange but sometimes you had no choice ...

             

            Cheers

            • 3. Re: StickySessionCookie with mod_cluster 1.3.1 + Wildlfly10 + Single Sign On in Undertow possible?
              pferraro

              Michael Koller wrote:

               

              Hi Paul

               

              The JSESSIONID is only the "default" value in the subsystem (undertow/balancer and so on)

               

              With Jboss (Tomcat) i can change the "Sticky"-Session Property trough a system property (org.apacher.cataline.JSESSIONID xxx).

               

              In the undertow-core, there are the setter (Balancer.java and BalancerBuilder.java) for the StickySessionCokieName (default is JSESSIONID) cause many Application have other Cookies (sepcial for domain tracking and so on). But i could not get my patches working, cause the System is really hard do debug/track to change that "default"-Value (im still in Progress). The standalone.xml does not provide a attribute to propapgate that value (just for "force" and "remove" ...)

              The "org.apache.catalina.JSESSIONID" system property in older JBoss releases was used to change the name of the cookie used to store the session ID.  This cookie is how the server knows to which session a given request is associated.  Sticky sessions work by appending a node identifier to the session ID.  The load balancer is able to read this cookie from the HTTP header and parse out the node identifier, and thus be able to direct traffic to the expected node.  Changing the name of the session cookie, apart from violating the servlet specification, doesn't buy you anything, since this doesn't change the routing behavior.

               

              I can manage a simpe HTTP-System with mod_balancer_proxy where i can set the sticky-cookie-name to balance (but i will use mod_cluster if it is possible in a way, cause we use a complex Stack and the jboss_modcluster can easy handel that stuff) so my idea is to change the stikysessioncokiename to the JSESSIONIDSSO in the "mod_cluster_system"

              The JSESSIONSSOID cookie is used to store the value of the single sign-on ID.  The server maintains a mapping of which session IDs are associated with a given single sign-on ID.  Conflating JSESSIONID with JSESSIONSSOID is dangerous, since these are distinct concepts.

               

              We have a complex distributed System with legacy-security-stuff (3-parties) and we cannot replicate that stuff (no way, we tried a lot). So we must do some "special"-Things like the "Sticky-SSO-Session". I know that's strange but sometimes you had no choice ...

              EAP7 does not support routing based on SSO IDs, which I think it what you are trying to do.  This would require an RFE.

              • 4. Re: StickySessionCookie with mod_cluster 1.3.1 + Wildlfly10 + Single Sign On in Undertow possible?
                koller.michael81

                Hi Paul

                 

                I see, i see. I thought i have noch chance :-) cause my use-case is broken by design....

                 

                I tried to bring the Application together. Maybe i have a chance to call the iframe (PDF-Viewer) with a subsequent-request with some cookie/script-hacks to use the "default-routing-behaviour".

                 

                Maybe i have more Luck.

                 

                Thank you for the Informations

                 

                Cheers Michael