0

My stack looks like this:

  • Apache httpd server 2.4.12: with mod_shibd, mod_proxy_http & mod_proxy_wstunnel
  • Shibboleth 2.5
  • Apache Tomcat 7.0.54

Our scenario looks like this:

    ---------        --------------        ---------------
    |Browser| <----> |Apache httpd| <----> |Apache Tomcat|
    --------- HTTPS  --------------  HTTP  ---------------

The apache httpd configuration:

<LocationMatch (^/test-websockets/.*)>
 AuthType Shibboleth
 ShibRequestSetting requireSession true
 ShibUseHeaders On
 ShibExportAssertion Off
 Require valid-user
</LocationMatch>
ProxyPass /test-websockets ws://db-00032:13042/test-websockets
ProxyPassReverse /test-websockets ws://db-00032:13042/test-websockets

The apache-tomcat http connector:

<Connector port="13042" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="13043" maxHttpHeaderSize="65536"/>

And finally the applications(s), any of the websockets samples that comes with the /examples applications of the binary tomcat distribution.

The good news are that the websockets application and the shibboleth SP work! So I can play the good and old snake video game being authenticated by our SSO and authorized by my shibboleth SP, hooray!

enter image description here

But, there is always a but, the bad news are that if I request the also good and old /servlets/servlet/RequestHeaderExample my shibboleth headers are not there, no bueno!

enter image description here

Enabling the Request Dumper Filter in the application I can see the HTTP request headers that hit the apache-tomcat:

===============================================================
 START TIME        =26-Apr-2016 15:59:36
         requestURI=/test-websockets/servlets/images/return.gif
           authType=null
  characterEncoding=null
      contentLength=-1
        contentType=null
        contextPath=/test-websockets
             cookie=_ga=GA1.2.1832568672.1461567525
             cookie=_saml_idp=aHR0cHM6Ly9jZXJuLmNoL2xvZ2lu
             cookie=_shibsession
             header=host=
             header=user-agent=Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
             header=accept=image/png,image/*;q=0.8,*/*;q=0.5
             header=accept-language=en-US,en;q=0.5
             header=accept-encoding=gzip, deflate
             header=referer=
             header=cookie=
             header=connection=keep-alive
             header=if-modified-since=Fri, 26 Sep 2014 13:25:30 GMT
             header=if-none-match=W/"1231-1411737930000"
             header=cache-control=max-age=0
             locale=en_US
             method=GET
           pathInfo=null
           protocol=HTTP/1.1
        queryString=null
         remoteAddr=128.142.201.245
         remoteHost=128.142.201.245
         remoteUser=null
 requestedSessionId=null
             scheme=http
         serverName=THE ONE DECLARED IN THE APACHE HTTPD VIRTUALHOST SECTION
         serverPort=80
        servletPath=/servlets/images/return.gif
           isSecure=false
 ------------------=--------------------------------------------
 ------------------=--------------------------------------------
           authType=null
        contentType=null
             header=ETag=W/"1231-1411737930000"
         remoteUser=null
             status=304
 END TIME          =26-Apr-2016 15:59:36
 ===============================================================

However when I force the browser cache (Ctrl+F5) I get my headers:

enter image description here

OK, I can see that now in the host header I am getting the apache-tomcat one, however I do not think that it has something to do with the issue, or maybe I am wrong?

Any thoughts on this?

Thanks in advance,

Luis

PS: I am wonder if this could be related with the --enable-proxy_wstunnel=shared option See "tunneling secure websocket connections with apache"

Community
  • 1
Gaucho
  • 101
  • 2
  • have you filled in the attribute-map.xml? and what is coming in your saml assertion? – Sum1sAdmin Apr 26 '16 at 15:05
  • Hello @Rob-d. attribute-map.xml: yes it is filled. saml assertion: once the user authenticates against the IdP this last one responds to my shibboleth SP with the right user data in the assertion, so all good from this side, thanks! – Gaucho Apr 26 '16 at 15:31
  • then, is this not expecting for SSO?, new headers with private browsing session or shib session on the idp expires. – Sum1sAdmin Apr 26 '16 at 15:45
  • Hello @Rob-d. mmm, none of them I am afraid. I can see that the session id keeps the same. And in that case I would be redirected to the IdP. Nevertheless I am going to double-check. thanks! – Gaucho Apr 26 '16 at 17:14

0 Answers0