[EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

[O'Quinn, Dennis]

Thank you sir,  that is surprising…  It is my personal workstation and I cannot imagine how it could be changing its IP address…  That should be static for the time of my connection to the network…  Not aware of any virtualization being done on behalf of my session(s).  There may be something going on with the way the application web server is managing/building my session with it when I attempt to invoke the target URL. I do not know, but again, I can’t imagine how that would be reflected as an ip address change on behalf of my PC…  Also, those IP addresses are from the corporate network and the application is running in the cloud with a completely different range of addresses.  Not sure that you would be interested in this, but, it would take a bit to explain it all.

Now, the reason I think the consistentAddress parm is the problem is that I think this is actually an application design issue.  What is happening is that the application has a ‘world’ facing web server.  This web server takes care of being the middleman for the traffic into the application (SAS).  The application has a compute service that runs on a separate server.  The web service authenticates you on one server and all the session info is set up for that server.  Then the application immediately passes you to the compute server which is the actual target the user was shooting for.  This function will be starting processes under the users ID on that server and thus it too needs to authenticate you.  When that is attempted with the current cookie, it is invalidated because the ip address is different since it’s a different server.  This triggers a new call to the IdP which recognizes (and approves of) the attached cookie/token and just turns it right back around to the SP which again attempts to open a session with the compute server  and around and around we go….

Are you thinking that I have something else going on?  I was unaware that the IP addresses in that log entry for the create sessions was (supposedly) the IP address of my device/browser until a post from David mentioned it a short time ago.  SO, no matter what those addresses are, I don’t think I know what’s going on after all…  It *could* be that the GCP LB is presenting a generated IP address (in a NAT sense so to speak) for my sessions as the transaction travels through it, but I don’t think that is the case.

I really thought that the looping was caused by the 2 relevant SAS servers and the authentication occurring on one before the session was passed to the second.

Gee thanks…  I thought I had it all figured out and here you go throwing a wrench into the middle of all my (supposedly) clean logic…  I will dig into this tomorrow.  Can you suggest which logs would be best for evaluating this?  Or perhaps just Fiddler and walking through all the traffic as it passes through?




From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> On Behalf Of Lipscomb, Gary
Sent: Wednesday, June 6, 2018 8:25 PM
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: RE: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

<quote>The consistentAddress setting was indeed the culprit, so I don’t want to waste other’s time in the group,/quote>

That’s not the culprit. You need to find out why your client’s addresses are constantly changing. You are only masking the problem by turning that off.

Gary

________________________________

The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180607/041ff8e0/attachment.html>