https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #10 from dub...@gmail.com ---
First off, what I'm asking for already exists in mod_jk via the JkEnvVar
directive. I just want the same thing for jk_isapi_plugin (the IIS equivalent
of mod_jk).
This request stemmed from a deep dive into an issue I've been researching
related to IIS and Adobe ColdFusion. ColdFusion installs the Tomcat connector
for the server that its set up to run within. I think you run it by itself
(basically running Tomcat by itself) but its recommended to run within a web
server for additional security (lord knows its a target vector) and ease of
setup. For my organization, that server is IIS so it installs the IIS
connector (isapi_redirect.dll) and requests get sent through IIS to
ColdFusion/Tomcat via AJP. This is an out-of-the-box install.
Now - we have another module/filter installed in IIS which handles SAML
authentication called Shibboleth Service Provider. By default, the Shibboleth
SP software manipulates the request and after its performed authentication of
the user, it stores REMOTE_USER and information about how they authenticated in
request attributes/variables. Those attributes are made available to
applications as part of the environment. For things like PHP, you can access
them via $_SERVER["some_var"]. For ASP, its
request.ServerVariables("some_var") for Java/JSP its
httpServletRequest.getAttribute("some_var").
Because the IIS connector doesn't pass any of this information on to Tomcat, I
cannot access it within my ColdFusion code. Luckily the Shibboleth SP software
has an option to store the information in request headers, but it strongly
recommended to not do this because those can be spoofed by the client.
So long story short, I absolutely need REMOTE_USER from IIS so I need AJP. The
jk_isapi_plugin provides this (yay). However I cannot access the request
variables that other modules/filters may set in IIS. For Shibboleth SP, I'm
forced to tell it to store the information in headers - a security risk
arguably more severe than using AJP.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
