Coldfusion 11 update 14 breaks Shibboleth

[Tonyam]

I am running the Shibboleth login service on my ColdFusion 11 server.  After I installed update 14 my Shibboleth login stopped working.  All I get now is a "Bad Request" error following Shibboleth authentication. I uninstalled the update which got Shibboleth working again, but now I am looking for possible solutions to this problem before reapplying the update.  I think it may have to do with the Tomcat update to 7.0.85.  Does anyone have any thoughts on this?

[Dave Watts]

I would try reinstalling it. I wouldn't be surprised if something broke it, and it will probably take you less time to reinstall it than to figure out the root cause.

Dave Watts, Fig Leaf Software

[Tonyam]

Tried that, still receiving Bad Request error after logging into a shibboleth protected site.

[cfnoob · Accepted solution]

I am also seeing this behavior on multiple servers running ColdFusion 11 Update 14. However, not all users are affected. It appears to depend on the total size of attributes being returned by Shibboleth. This led me to what I believe is the root cause: the AJP connector enforcing a max packet size of 8192 (instead of 65536). (Assumption here is that prior to Update 14 the AJP max packet size limit was 65536).

To test the potential fix, you can add the following value to the AJP Connector tag in <ColdFusion Root>\cfusion\runtime\conf\server.xml:

packetSize="65536"

If you're curious to see what size packets are being passed to the connector:

(note: this will grow your isapi_redirect.log file very quickly, so use with caution - preferably only on dev servers)

1. Set log_level to debug in <ColdFusion Root>\config\wsconfig\<#>\isapi_redirect.properties
2. Check <ColdFusion Root>\config\wsconfig\<#>\isapi_redirect.log for entries like:
   ajp_connection_tcp_send_message::jk_ajp_common.c (1326): sending to ajp13 pos=4 len=8505 max=65536

Note: It is uncertain to me what, if any, side effects may occur as a result of explicitly setting packetSize to 65536.

[hammo7]

In case it helps anyone else, We had similar 'Bad Request' errors and had to apply the packetSize fix after install update 14.  We don't use Shibboleth, but we saw that some clients received the 'Bad Request' error due to the size of the cookies being passed to the server with each request.  Another odd symptom was that requests for 'root' pages that did not include a '.cfm' filename (that did load a .cfm as default document) did work.  For example,  mysite.com/subdirectory (IIS serves index.cfm as default document) worked but mysite.com/subdirectory/index.cfm failed with a 400.0 Bad Request error.

[Dave Watts]

In case this helps anyone: requests without an /index.cfm file are treated differently by IIS than requests with one. One goes through the /jakarta virtual directory mapping, the other goes through the ISAPI mappings that are defined for the site. I don't know why they'd give you different results, but my recollection of Shibboleth IIS configuration was that everything would give you different results, so there you go.

Dave Watts, Fig Leaf Software

[hammo7]

I figured it was something like that, but had no luck trying to compose a Google search that would return relevant results.  Glad to know I am not crazy.