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