AJP proxy of request environment
Russell Beall
beall at usc.edu
Fri Jul 20 17:21:37 EDT 2012
Hi Scott,
Thanks for all your responses today (and pretty much every day)!
On Jul 20, 2012, at 12:43 PM, Cantor, Scott wrote:
> On 7/20/12 3:22 PM, "Russell Beall" <beall at usc.edu> wrote:
>>
>> It seems that this was a design decision for certain specific performance
>> reasons. The attribute names and values do exist in the request if I
>> explicitly call them by name, but the names are not being provided in the
>> enumeration.
>>
>> Has anyone found a way around that besides switching over to Jetty
>> completely?
>
> Is that really a requirement in general? Other than for debugging, what's
> the use case?
I thought Jetty was being recommended as the container for production use. If it is not, then I'll stick with Tomcat in production.
However, I was not discussing Apache --> Java container connection issues in relation to the IdP in this message. I am asking about how it should work with an SP in front of a Java application.
>> Since the Shib project is switching to recommending Jetty, I wanted to
>> move in this direction, but their documentation about AJP seems to
>> indicate they think it should not be used, and so they probably aren't
>> giving it the attention it deserves.
>
> I'm not sure what the issue is, but I don't know what the maven plugin is
> for. AFAIK, they support AJP connectivity, but I don't actually run it
> that way myself, and the switch to Jetty is certainly not focused on a use
> case involving the SP or Apache in front of the IdP.
The maven plugin allows for a development servlet to run directly out of the project without having to deploy a war file elsewhere. I have used this both in application development as well as testing IdP plugins from an IdP run directly from the command "mvn jetty:run"
>> If I am understanding this correctly however, AJP would be critical to
>> the security of passing request data to a Java application behind an SP
>> in Apache because using the application headers is subject to spoofing.
>
> That doesn't really have anything to do with the IdP, though, and that's
> the Java component that is focused on Jetty.
>
> And, FWIW, it's not subject to spoofing, it's at risk to bugs in the
> protection against spoofing if a server or API changes the way they handle
> headers. Anybody is welcome to try attacking it any time.
So with this info, and the response that Chad made a moment ago, it appears that I can send headers into a Java application with the same level of security as using AJP and it doesn't really matter which one I choose.
If this is the case, then why does the SP documentation recommend against "ShibUseHeaders On" in favor of using AJP and setting the variables to have the "AJP_" prefix which causes them to be forwarded as request attributes to the application?
The wording on this in the documentation has gotten even stronger since last I read it which is why I decided I'd better understand what was going on. Prior to this I have been telling departments to use "ShibUseHeaders On" so that the data shows up to their application, since I couldn't advise them on how to do it with environment variables.
>
>> Is there a way to use the HTTP proxy, which is what the Jetty
>> documentation highly recommends, and still keep the data secure and free
>> of potential spoofing? I couldn't seem to proxy any request attributes
>> this way, but only headers.
>
> You may be able to generate proxied headers from environment variables,
> but I don't know for sure.
Nope. Wasn't talking about some special case like this, just the standard "to use headers, or not to use headers" quandary…
Regards,
Russ.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list