[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: Configuring logback.xml to log X-Forwarded-For/Client IP in audit logs in IdP v3
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2017-01-29 17:33:03
Message-ID: 878B40AD-CDCB-466D-A0D8-ED8A9A8A7B9A () osu ! edu
[Download RAW message or body]

On 1/28/17, 1:36 AM, "users on behalf of Sheldon, Nathan I" \
<users-bounces@shibboleth.net on behalf of Nathan.Sheldon@ucsf.edu> wrote:

> Got it.  Found it in the documentation at https://logback.qos.ch/manual/mdc.html

Well, that's the general thing, but we already document the fields we supply, I gave \
you the link.  
> Ha!  I've found that assumption to be false of many enterprise \
> applications/vendors.  The F5 documentation at \
> https://support.f5.com/csp/article/K4816 seems to indicate that it generates it's \
> X-Forwarded-For header using the value of the IP address in the packet in which the \
> HTTP/S request was made.

Yes, but if the client sends one, does it overwrite it? The NetScaler does not.

> Added to /opt/shibboleth-sp/edit-webapp/WEB-INF/web.xml above the "<!-- Manages \
> logging MDC. —>" section, then executed /opt/shibboleth-idp/bin/build.sh to \
> deploy the change.

That is not necessary. We already give you a filter that populates idp.remote_addr

You should NOT log based on X-Forwarded-For. That means the configuration has to \
change just based on how you have deployed things, vs. just logging the client \
address the container sees.

If getRemoteAddr() isn't accurate itself, you'd have an insecure system.

-- Scott
    
    
    
    
    
    
    

-- 
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]