
<html><body>Our IdP behind a load balancer obtains and records the client IP address in the x-Forwarded-For header.<div>Users of some services also behind load balancer are nevertheless being prompted to reauthenticate because</div><div>the IdP refuses to proceed with the recently established SSO session, citing IP address mismatch:</div><div><br></div><div><pre class="c-mrkdwn__pre" style="box-sizing:inherit;margin-top:4px;margin-bottom:4px;padding:8px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;border:1px solid var(--saf-0);border-top-left-radius:4px;border-top-right-radius:4px;border-bottom-right-radius:4px;border-bottom-left-radius:4px;background:rgba(var(--sk_foreground_min,29,28,29),0.04);color:rgb(29,28,29);font-family:Monaco,Menlo,Consolas,"Courier New",monospace!important">Client address ....114.251 invalid for session 011...bf113 bound to ....0.22</pre></div><div> </div><div>The “bound to” address at the end is the correct client IP address; the “Client address” at the beginning</div><div>is one of the addresses of the load balancer.</div><div><br></div><div>Two questions:</div><div><br></div><div>What would trigger a Shibboleth SP to request validation or re-authentication for some users (but not others)?</div><div><br></div><div>How is the IdP getting the load balancer IP address as “client address”? - Does the SP request include what it thinks is the client IP address, or is the IdP not getting the correct x-Forwarded-For header on this request, even though it did so on the initial request that established the SSO session?</div><div><br></div><div>David St. Pierre Bantz</div><div>U Alaska IAM</div></body></html>