Jetty + REMOTE_USER

[John Dennis]

On 09/12/2015 02:41 PM, Matthew Slowe wrote:
> On Sat, Sep 12, 2015 at 01:17:11AM +0000, Cantor, Scott wrote:
>> On 9/10/15, 8:35 AM, "users on behalf of Matthew Slowe" <users-bounces at shibboleth.net on behalf of m.slowe at kent.ac.uk> wrote:
>>
>>
>>
>>> I've mostly got it working however despite following the "Offloading
>>> TLS" instructions [1], I can't persuade the IDP to pick up
>>> the REMOTE[-_]USER header passed back by mod_proxy (I can see it going
>>> on a tcpdump -A).
>>
>> I wouldn't send a header with that name (it's just confusing) and
>> separately from that, I don't know how you're trying to pick it up.
>> You certainly can't just leave things defaulting to reading
>> REMOTE_USER. That's not a header. You have to actually specify a
>> header name to read from in the configuration of that login flow (in
>> V3 anyway). That's just the trade-off with the mod_proxy_http
>> approach.
>
> I assumed, perhaps wrongly, that IDP inside Jetty would work similarly
> to Tomcat where the REMOTE_USER in Apache is passed back via AJP and
> found various hints on the internet to suggest this ought to work.
>
>>> In Tomcat land I would have set the tomcatAuth=false but can't see what
>>> to do with Jetty instead.
>>
>> Nothing. You're equating use of REMOTE_USER with use of a header, they're not all the same.
>
> I was using the REMOTE_USER environment variable in Apache land and
> passing it back as a header to Jetty... unless there's a better way to
> do this?
>
>>> Would it be better to just run with the v3 IDP instead?
>>
>> If you're not running with V3 to begin with, I don't recall if V2's RemoteUser handler could read from headers off hand.
>
> It got it via AJP ok :-)
>

Jetty 9 dropped support for AJP. AJP is how REMOTE_USER is exposed as 
HTTPServletRequest.getRemoteUser() on the servlet side. If you don't 
have AJP then you're forced to pass via some other mechanism, e.g. in 
HTTP headers. You can emulate what AJP was doing on the servlet side by 
adding an HttpServletRequestWrapper filter which extract what is pass in 
via headers (I've attached the code from another project which does that).

This document, written for another project explains the issues, see the 
Appendix in the section on "CGI Export Issues". Other parts of the 
document also touches on it.

You also need to be careful when forwarding REMOTE_USER via a proxy 
because the receiving end of the proxy believes the presence of 
REMOTE_USER unequivocally indicates the user has been authenticated. 
It's very easy to inject REMOTE_USER into a forged request, therefore 
it's essential you limit the receiving servlet to listen only on a port 
you trust is devoted exclusively to your Apache front end, the document 
discusses some of those issues as well.

https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf

HTH,

-- 
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SssdFilter.java
Type: text/x-java
Size: 5246 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20150913/6bc0ee0a/attachment-0001.bin>