-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 John,
On 7/28/15 4:10 PM, John Baker wrote: >> I haven't looked too closely, but I'm not sure what "standard" >> mechanisms there are to communicate this through a proxy. >> variables don't pass through a proxy, and a HEADER is NOT the >> proper solution here unless you also implement something similar >> to the Tomcat RemoteIpValve where you have the notion of >> trustedProxiesForAuth or something like that. > > Neither AJP forwarding REMOTE_USER or an HTTP header is great, so > if we all care about security, that feature of mod_jk needs > disabling with warnings/sirens should one enable it. This conversation is becoming tiring. You are complaining about how insecure the implementation of tomcatAuthentication="false" is in the AJP connector and your proposal is to *extend that insecure capability to the HTTP connector*? In fact, you want it to be even /more fragile/ and /less secure/. Sigh. > I do appreciate the remote IP valve exists, but this is a sticking > plaster around the core design flaw. I assert that the AJP connector is more secure than tunneling the REMOTE_USER through HTTP headers using the HTTP connector. > However, it is true that plenty of vendor modules exist in the > Apache HTTPD world that forward a username on a header (I've listed > some) and with the appropriate controls in place, it isn't an awful > solution to use an HTTP header to carry the username. It's no > different to mod_jk forwarding REMOTE_USER (mod_jk isn't providing > security in our puzzle). AJP's handling is slightly more secure, because it does not transmit this information via HTTP headers, which can be controlled by the client . - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVt+QjAAoJEBzwKT+lPKRYEpoP/33y56tgu75D5Y5aVeWGuR6e aNIHWAq9bHRWb14VuEsDYUT0oT7WKEqhpca0Vb//mDgTu0MX+751Tw3nHk5F7WoJ 8XMYMWafLTLQ9/ryMD1aXhTKmkpFY81pt5FsAuTNHpX291xNghAa3IfArbxm6e6A eWH4/ypyNgW2HHVnheWu9hcYT+ANItEQIPsxV+EETwnkvtPZWLmG386qNYpX+dc2 WWEYPMSrbURaQyKPIsyMXZrws1/cDydchIgoeHnNJIXck+WZJBLlMv1UJWct7Fpa lHTte8Jali4hEySjjb/LEb5BMEw4f6ZpB/SBIr/Aq693hfKEM74gQD4FFBYySlcn +1hrYaSPB7yGZ/qORVC3fntYzj4WTj0QoY8tQVTbzBym2r8D3RD2RK+6G/QXdl2e SYL1KKFjlIxDQ3l81H9pP9yPvm59l7jQJ6HHCt4DkvenejyFLO8rzGzzmAJV/E2v SxF5xX3pmaSRkB51QshoWU9VqJR/OUjKeGgbuzqQ2EF3pFrNCi2ZxedUyXdwRBzO KU8sR4jypXZAnKiGzgACisWuTfgDAiwmL3zSfzGnXDWhuOvAsoIzpMpPbyTSMq/4 7QqvsQONg4vEtSXOfatNrvk05SLfLVUNoTrr21bT4q+tLSK4N/FYwuz+oarHLbL8 FKruttNG9JTWa4ZRGSXO =boet -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
