3 Replies Latest reply on Aug 21, 2015 8:39 AM by David Allen_993

    Losing Header Information from Siteminder


      We have been working to migrate several of our internal CF8 sites over to a new CF11 server. I have only been supporting CF for about a year, so I'm afraid I am not as knowledgeable as I should be.


      Most of our sites are working correctly; however, we are encountering a unique issue with a site called Workforce Tracking. It utilizes a header variable (RACFGROUPS) that is returned by Siteminder. This is handled by the application.cfm file, with the relevant section below:



      When I navigate to devworkforcetracking2.localnetwork.com/Jobs/, the default index.cfm page gets loaded, the application file is called, and the RACFGROUPS header information is available. I have been using CFOUTPUT on the variable for debugging:




      However, if I try to navigate to workforcetracking.localnetwork.com/Jobs/index.cfm (or any site under /Jobs/), I receive this error message:




      This is despite the fact that the exact same index.cfm file is being called.


      I contacted our Siteminder team, and they provided me with a file to test if the RACFGROUPS variable is being received by other file types inside that folder. The header information is working correctly for their test file.


      As far as we can tell, our setup between CF8 and CF11 is identical. We have been picking over this site for quite some time, trying to figure out why the header information is available for /Jobs/ but not for anything under it, and we have not had any luck.


      Anyone run into this before? Any advice?

        • 1. Re: Losing Header Information from Siteminder

          In my case, if I show headers via an ASP page, I see all 27 headers.  When I show the same headers from a CFM page, I only see 24 headers.  And the 3 missing headers are the last 3 headers listed on the ASP page.


          I have enabled debug logging for isapi_redirect.log.  The log only shows 24 headers (see below).


          Is there a limit to the number of headers that isapi_redirect.dll supports?


          I am running ColdFusion 11 Enterprise on Windows Server 2008 32 bit.



          [Tue Nov 04 10:26:00.940 2014] [8800:8912] [debug] init_ws_service::jk_isapi_plugin.c (3944): Forwarding request header usertype : Employee

          [Tue Nov 04 10:26:00.940 2014] [8800:8912] [debug] init_ws_service::jk_isapi_plugin.c (3973): Service protocol=HTTP/1.1 method=GET host= addr= name=devasicint.internal.local port=80 auth= user= uri=/secureint/headerinfo.cfm

          [Tue Nov 04 10:26:00.940 2014] [8800:8912] [debug] init_ws_service::jk_isapi_plugin.c (3985): Service request headers=24 attributes=0 chunked=no content-length=0 available=0


          • 2. Re: Losing Header Information from Siteminder
            Archebius Level 1

            I don't think that's the issue in this case, since they will appear for the default site, but not when I call the page specifically.


            Even stranger, the header information will appear for ANY site that I have set as the default document in IIS. It is only when I call the .cfm file by name - e.g, index.cfm, SupView.cfm - that it fails to pass the information.

            • 3. Re: Losing Header Information from Siteminder
              David Allen_993

              I realize this is little consolation to those experiencing this issue (since the OP was almost a year ago now), but wanted to chime in with my two-cents.  I am currently migrating our sites from CF9 Enterprise to CF11 Enterprise, all servers running Windows 2008R2 and IIS 7.5.  Our sites use DoD SiteMinder for authentication, which sets various headers that should be passed from the SiteMinder Policy Server to IIS, and then be forwarded on to Tomcat for accessibility in ColdFusion.


              In CF9, this works flawlessly.  In CF11, not so much.


              From what I'm reading online through various forums (details are few and far between, and very difficult to find), there is something wrong with the IIS/Tomcat Connector that ships with CF11.  I am not an expert in IIS or Tomcat by any means, but I was able to get my hands on enough log files to see what's happening, and figured I'd document what I did here for anyone who may run into this issue in the future.


              In IIS, there are "Handler Mappings" that force *.cfm (and other ColdFusion extensions) to utilize the ColdFusion's "c:\{install-path}\config\wsconfig\{magic-number}\isapi_redirect.dll".  Inside this {magic-number} folder, there should also be a file named "isapi_redirect.properties" that contains an entry for "log_level" that is set to "info" by default.  If you change this value from "info" to "debug" and restart your server, you will get a log file containing a heck of a lot of useful debug information.


              Make a page request on your server (in my case, it was to access a template protected by SiteMinder), and then go check the contents of the "c:\{install-path}\config\wsconfig\{magic-number}\isapi_redirect.log" log file.  You should see entries in there for "Forwarding request header {name}: {value}"


              In my case, the last 3 headers set by SiteMinder were NOT being forwarded to Tomcat... meaning that they were undefined in ColdFusion.  I don't know why they weren't, but they weren't.


              After hours of research trying to find a workable solution to this, it hit me: why not have SiteMinder set 3 fake/static fields that are alphabetically last (and thus be the last 3 set and forwarded)?  This would mean that all the fields ColdFusion is expecting from SiteMinder WOULD be forwarded, while the 3 fake/static fields WOULD NOT be forwarded.


              Turns out: this worked.  I'm now getting ALL headers from SiteMinder and the 3 fake/static fields are being lost out there somewhere in transmission.


              Here's a link to a discussion about the IIS/Tomcat Connector bug.  From the latest comments, it looks like it was fixed... but has resurfaced in Windows 2008 and IIS 7.5... surprise, surprise.  I can't find anything anywhere suggesting that somebody is fixing this issue with the latest connector, but at least I outsmarted the problem... for now.

              Bug 47679 – Not all headers get passed to Tomcat server from isapi_redirect.dll


              Hope this helps somebody else who may have the same problem, but can't (like me) find a workable solution.