RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

O'Quinn, Dennis
I have a problem that I can't seem to get past. I have included below my configuration, a description of my problem, and the first 7 header entries from a fiddler trace showing the behavior.  If anyone could provide direction on how to further diagnose or correct this, it would be greatly appreciated....
If I can provide any other info to aid in solving this problem, please let me know.
Config:
************************************************************************************************************************************************
IdP:
I have  a PingIdentity IdP in a corporate network that is behind a firewall/loadbalancer with multiple servers providing the IdP function.
They use NetScaler with the Persistence type set as COOKIEINSERT to insert a cookie in the clients request in order to maintain server/session affinity on their end (I do not know yet how to validate how well this is working however).
The host name for the IdP is https://thdsaml-qa.<corp>.com
************************************************************************************************************************************************
SP:
I have Shibboleth running on a Linux Compute server in Google Cloud Platform (GCP) with an application that runs its own Apache/Tomcat server.
The GCP Compute server's host name (I.e., the SP) is sas-mao-midtier.<gcp-project>.internal.
There is a GCP load balancer at the network boundary between the corporate network and GCP.  The LB is configured for HTTPS on the front end (facing the corporate network) and HTTPS on the back end facing the application.  It routes traffic only to the application on port 8343.
The GCP LB has a DNS entry defined in the corporate network as sascloud.<corp>.com.  This is the name by which sas-mao-midtier is known from the corporate network.
************************************************************************************************************************************************
Application URL for the SAML is defined in the Virtual host configuration in Apache httpd-ssl.conf file as follows:
<Location /SASLogon/login>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require valid-user
  RewriteEngine On
  RewriteCond %{LA-U:REMOTE_USER} (.+)
  RewriteRule . - [E=RU:%1]
  RequestHeader set X-Remote-User "%{RU}e" env=RU
</Location>
The server name and alias directives in http-ssl.com are defined as follows
<VirtualHost _default_:8343>
.
ServerName sascloud.<corp>.com
ServerAlias sas-mao-midtier.<gcp-project>.internal:8343
************************************************************************************************************************************************
Info from the SP metadata:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_debcbeb52323232824dc272e407f90bb7fc6ace9" entityID="https://sascloud.<corp>.com/shibboleth">
  <md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport">
  </md:Extensions>
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
    <md:Extensions>
      <init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://sascloud.<corp>.com/Shibboleth.sso/Login"/>
    </md:Extensions>
    <md:KeyDescriptor>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>sas-mao-midtier</ds:KeyName>
        <ds:X509Data>
          <ds:X509SubjectName>CN=sas-mao-midtier</ds:X509SubjectName>
          <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sascloud.<corp>.com/Shibboleth.sso/Artifact/SOAP" index="1"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sascloud.<corp>.com/Shibboleth.sso/SLO/SOAP"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sascloud.<corp>.com/Shibboleth.sso/SLO/Redirect"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sascloud.<corp>.com/Shibboleth.sso/SLO/POST"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sascloud.<corp>.com/Shibboleth.sso/SLO/Artifact"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML2/POST" index="1"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML2/Artifact" index="3"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML2/ECP" index="4"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML/POST" index="5"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://sascloud.<corp>.com/Shibboleth.sso/SAML/Artifact" index="6"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>
************************************************************************************************************************************************
Problem:
First, a test to the IdP returns our SAS splash page with no problems (url: https://thdsaml-qa.<corp>.com/idp/startSSO.ping?PartnerSpId=https://sascloud.<corp>.com/shibboleth)
However, that base page (https://sascloud.<corp>.com is not 'protected' by Shibboleth/SAML, so, we get the same page via https://sascloud.<corp>.com (i.e., no routing through SAML).
Our problem is that when we attempt to invoke the actual application, our login goes into a loop on the SAML2/POST immediately after the successful authentication.
The problem appears to be that the application is not recognizing the assertion and is immediately kicking it back to the IdP for authentication as though it is a fresh session.
************************************************************************************************************************************************
Header Printout from Fiddler:

First call to IdP for login:
GET https://thdsaml-qa.<corp>.com/idp/PECJM/resumeSAML20/idp/SSO.ping HTTP/1.1
Host: thdsaml-qa.<corp>.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://thdsaml-qa.<corp>.com/thdsso/logon.jsp?resumePath=%2Fidp%2FPECJM%2FresumeSAML20%2Fidp%2FSSO.ping
Cookie: _vwo_uuid_v2=D4A207004D164465DF5A2C4F65B13EDEF|9cf24f88a390e29700f1e0e362ecf9c9; visid_incap_996692=kMugpANRRt6l+uCwnMjNXb8xe1oAAAAAQUIPAAAAAACauoqucnVwbPXDKk76479Z; _ga=GA1.2.271266464.1517503567; s_vi=[CS]v1|2D38E4C80507DBF8-4000010460003BF0[CE]; LPVID=RlMThhZjk0MDkwN2U0MGFj; _vis_opt_s=1%7C; _vwo_uuid=D070FCAC86C261ED2B3E2B16A15F3CFEF; _vis_opt_exp_2_combi=1; _abck=B5BE87F7A085FBFE166C0FCEA50AA669B81C7F0D071F0000C856E85AF636B675~0~IEOqYPpHT6/zlgy0PesxnKZy7Zg+7hxTnqw2zFDZNkM=~-1~-1; THD_CACHE_NAV_PERSIST=; ftr_ncd=6; thda.u=f9dbcda9-9991-a0c5-c609-9f5a830c0bd4; p_seg=seg1%3D7183005; RES_TRACKINGID=367400434790740; mbox=PC#f3dc3719fdd54d408b332525bcc2cbee.17_41#1588420810|session#d493ed9556874c66970b67f1f6f38759#1525216224; forterToken=d3077b5064204c0d9a466cd3899ff3a6_1525214363690__UDF4_6; s_pers=%20productnum%3D1%7C1527768083263%3B%20s_nr%3D1525214365203-Repeat%7C1556750365203%3B%20s_dslv%3D1525214365207%7C1619822365207%3B%20s_dslv_s%3DLess%2520than%25201%2520day%7C1525216
 165207%3B; THD_PERSIST=C4%3D121%2BCumberland%20-%20Atlanta%2C%20GA%2B%3A%3BC4_EXP%3D1556712013%3A%3BC24%3D30339%3A%3BC24_EXP%3D1556712013%3A%3BC34%3D31.1%3A%3BC34_EXP%3D1525300765%3A%3BC39%3D1%3B8%3A00-20%3A00%3B2%3B6%3A00-22%3A00%3B3%3B6%3A00-22%3A00%3B4%3B6%3A00-22%3A00%3B5%3B6%3A00-22%3A00%3B6%3B6%3A00-22%3A00%3B7%3B6%3A00-22%3A00%3A%3BC39_EXP%3D1525179613; ctm={'pgv':93917700242109|'vst':6587122566013417|'vstr':3865677187556332|'intr':1525214365300|'v':1|'lvst':638}; AMCV_F6421253512D2C100A490D45%40AdobeOrg=-894706358%7CMCAID%7C2D38E4C80507DBF8-4000010460003BF0%7CMCIDTS%7C17653%7CMCMID%7C51736870787950132971209766123311017639%7CMCAAMLH-1525780809%7C7%7CMCAAMB-1525819165%7CRKhpRz8krg2tLO6pguXWp5olkAcUniQYPHaMWWgdJ3xzPWQmdj0y%7CMCOPTOUT-1525221565s%7CNONE%7CMCCIDH%7C353668118%7CvVersion%7C2.3.0; _br_uid_2=uid%3D2211865213621%3Av%3D12.0%3Ats%3D1525176014136%3Ahc%3D4; _4c_=hVNNT9tAEP0r1R44BXtm1%2FsVCVVJgKqVCqLQ9ojs9ZpYOLG16zStUP4743wgCrTkYM%2Fsvpl573nywNZzv2RjlFxyzIThHMSI3fs%2FkY0fm
 OuG56%2FhsQoNG7N533dxnKbr9TqZtwtf%2Bq7tE9cuUpdOuq6p86Xz8fayqnyIbMRcW3oqQ5tkCae8WjVV3TTXfRv851O6obNuFdw8jwPugtLC9zmFbajv6iXls6Z29zd5479vC1ATRQlCS2GkUmKoCO06%2BkCXs3kgUh%2BUHEYRd8Y1cqUylSUoUVOZVJruWlLHftbLkgopDZ7ohm0HymLdD1z%2BkkfHvQ%2BLoYzCy683326nZ5PZ5cUzT%2BI6j%2B6FK0UaY%2Fp01IW2TBHSL9fHPBEJpBEkCiO4MlZaqT9OrqYneLSoyxNiK5TRoI22ElBwS0rAaqWQC4EIqJWwRzlB%2BakwZ9nMkCv6dHpujjOgH0Km6CWm53A0uTo7wcFp%2BpIso6BpHRlKCX37Efs0ud15%2Bw%2B3tnJ%2F7BDvzWKbEfu92ycBoJW0iORdT8tj1BYMhAh1uV8sJoqsVICFoZGlKn1V2RwLV6BVrpS5pfnbfuSA5ICZtYoaDEq29dmrcfB63G5B%2FlPzFkV3YNiHlX%2FBQgKXA6bfY6q8if4FhCKCuKWjvu%2BA7kJ16HT4IxIrS0reAHeHfkR6L4NzM8gAu5eB2ZMM2qWDDqPLovK5kiV6o2SugRtjhNcawToFzzRa2BHYbDaP; GUID="abda4078-3906-d09f-5ff0-11fd3b50d92b"; pfidpaid=ad..SecureIDRSA1; JSESSIONID=1ovni8yzw8e1hbw1qtjktha5g; NSC_mc-wt-rb-443-w1-uietbnm=ffffffffaf1a890c45525d5f4f58455e445a4a421577; PF=FyMOrA5wCE5hJTJaQPzUD6tk4wEGnxghPJJC0QVrgLY0; sessionID=ji13vxb7-i.bzspnkqt73ta7; rssoSessionID=vTehB7chhVqPuMEJjCmqnTOE7ultufddgJ0oiFF/Xe6
 dAV2VcyI2JH9I/6cqCLms; THDSSO=GVnyCsTJCZaZDBya5CpDrh8RR2S6xGQ8rXOjrxOW9avQ4xB6Q7C9wZimKS77k0uhTKXIS05Snx7rdrmeeOsCNOuNmq8RX5g1yYPTgVpsrCvmWl3Q7RvhBg1Bdiu6BS7uWfbCX4wMSayIWRSg143U4Z6PtC9QuXbJhBRuuAJ0zXsfB1YYilLlju6JObTuefOyovIK4Nuq5rrUDsOtaTEpvrxb4Zj0uemAW0BRppZLIwOu1GQETSsad2jmGrHqdh6JlFejKFdRNQxA42lN7WLSq0K9ctjb52Ij71TkwUNnwh9ZwFkYBEIEJr1tYlntMjB4iHBuhGf06TUpajGh4q0BRl92jxUFLL6ZlJP4FpuNH92B2gHyvjxLIW6cm2AKQexKSr4YJqb14m5sqdpTuGfRj6bsaBP8wAtZkQ0yByrEHMEwfy3ARHLYib2lRbCetJC7X0wGwSJVgzkRz3yZ44YMEZpXGmxyvPw6TME1kUyEatLbtUp6gI2EK004q1v8ovQ5UEzEPhrYmjuZG03Y061K9Y3kQ7PFQy7A9vmCATSf6m5oFbJVSi0m0Ao9NQL2ZXclzMyJFmofghSA6vpKa2mnuQKuMTxzfIm79oIsQbC9GUX35MV0Se17GVXQoL8b3Hqy8P1BsIUUc2pz0xlAZz1r6aeUsTvSOUeVMYO9PVvE8lfj6So7DhyysxWDGQCLDU4xqcIwYQWv4Grm3M66cV4oUsRCLZbMAnJeKUDMkO2F5DgpFKVFXHnyryz7AoKPWybQReAqEjyZkM1HG8vXZWCg6JESndIUoVGU0PWHyyaT1wwCQ9XeU6RVoc6h0lxL
HTTP/1.1 200 OK
Date: Tue, 05 Jun 2018 03:09:54 GMT
Content-Security-Policy: referrer origin
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 8917

LOGIN SUCCESSFUL: POST BACK FROM SAML
POST https://sascloud.<corp>.com/Shibboleth.sso/SAML2/POST HTTP/1.1
Host: sascloud.<corp>.com
Connection: keep-alive
Content-Length: 8162
Cache-Control: max-age=0
Origin: https://thdsaml-qa.<corp>.com
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://thdsaml-qa.<corp>.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: _vwo_uuid_v2=D4A207004D164465DF5A2C4F65B13EDEF|9cf24f88a390e29700f1e0e362ecf9c9; visid_incap_996692=kMugpANRRt6l+uCwnMjNXb8xe1oAAAAAQUIPAAAAAACauoqucnVwbPXDKk76479Z; _ga=GA1.2.271266464.1517503567; s_vi=[CS]v1|2D38E4C80507DBF8-4000010460003BF0[CE]; LPVID=RlMThhZjk0MDkwN2U0MGFj; _vis_opt_s=1%7C; _vwo_uuid=D070FCAC86C261ED2B3E2B16A15F3CFEF; _vis_opt_exp_2_combi=1; _abck=B5BE87F7A085FBFE166C0FCEA50AA669B81C7F0D071F0000C856E85AF636B675~0~IEOqYPpHT6/zlgy0PesxnKZy7Zg+7hxTnqw2zFDZNkM=~-1~-1; THD_CACHE_NAV_PERSIST=; ftr_ncd=6; thda.u=f9dbcda9-9991-a0c5-c609-9f5a830c0bd4; p_seg=seg1%3D7183005; RES_TRACKINGID=367400434790740; mbox=PC#f3dc3719fdd54d408b332525bcc2cbee.17_41#1588420810|session#d493ed9556874c66970b67f1f6f38759#1525216224; forterToken=d3077b5064204c0d9a466cd3899ff3a6_1525214363690__UDF4_6; s_pers=%20productnum%3D1%7C1527768083263%3B%20s_nr%3D1525214365203-Repeat%7C1556750365203%3B%20s_dslv%3D1525214365207%7C1619822365207%3B%20s_dslv_s%3DLess%2520than%25201%2520day%7C1525216
 165207%3B; THD_PERSIST=C4%3D121%2BCumberland%20-%20Atlanta%2C%20GA%2B%3A%3BC4_EXP%3D1556712013%3A%3BC24%3D30339%3A%3BC24_EXP%3D1556712013%3A%3BC34%3D31.1%3A%3BC34_EXP%3D1525300765%3A%3BC39%3D1%3B8%3A00-20%3A00%3B2%3B6%3A00-22%3A00%3B3%3B6%3A00-22%3A00%3B4%3B6%3A00-22%3A00%3B5%3B6%3A00-22%3A00%3B6%3B6%3A00-22%3A00%3B7%3B6%3A00-22%3A00%3A%3BC39_EXP%3D1525179613; ctm={'pgv':93917700242109|'vst':6587122566013417|'vstr':3865677187556332|'intr':1525214365300|'v':1|'lvst':638}; AMCV_F6421253512D2C100A490D45%40AdobeOrg=-894706358%7CMCAID%7C2D38E4C80507DBF8-4000010460003BF0%7CMCIDTS%7C17653%7CMCMID%7C51736870787950132971209766123311017639%7CMCAAMLH-1525780809%7C7%7CMCAAMB-1525819165%7CRKhpRz8krg2tLO6pguXWp5olkAcUniQYPHaMWWgdJ3xzPWQmdj0y%7CMCOPTOUT-1525221565s%7CNONE%7CMCCIDH%7C353668118%7CvVersion%7C2.3.0; _br_uid_2=uid%3D2211865213621%3Av%3D12.0%3Ats%3D1525176014136%3Ahc%3D4; _4c_=hVNNT9tAEP0r1R44BXtm1%2FsVCVVJgKqVCqLQ9ojs9ZpYOLG16zStUP4743wgCrTkYM%2Fsvpl573nywNZzv2RjlFxyzIThHMSI3fs%2FkY0fm
 OuG56%2FhsQoNG7N533dxnKbr9TqZtwtf%2Bq7tE9cuUpdOuq6p86Xz8fayqnyIbMRcW3oqQ5tkCae8WjVV3TTXfRv851O6obNuFdw8jwPugtLC9zmFbajv6iXls6Z29zd5479vC1ATRQlCS2GkUmKoCO06%2BkCXs3kgUh%2BUHEYRd8Y1cqUylSUoUVOZVJruWlLHftbLkgopDZ7ohm0HymLdD1z%2BkkfHvQ%2BLoYzCy683326nZ5PZ5cUzT%2BI6j%2B6FK0UaY%2Fp01IW2TBHSL9fHPBEJpBEkCiO4MlZaqT9OrqYneLSoyxNiK5TRoI22ElBwS0rAaqWQC4EIqJWwRzlB%2BakwZ9nMkCv6dHpujjOgH0Km6CWm53A0uTo7wcFp%2BpIso6BpHRlKCX37Efs0ud15%2Bw%2B3tnJ%2F7BDvzWKbEfu92ycBoJW0iORdT8tj1BYMhAh1uV8sJoqsVICFoZGlKn1V2RwLV6BVrpS5pfnbfuSA5ICZtYoaDEq29dmrcfB63G5B%2FlPzFkV3YNiHlX%2FBQgKXA6bfY6q8if4FhCKCuKWjvu%2BA7kJ16HT4IxIrS0reAHeHfkR6L4NzM8gAu5eB2ZMM2qWDDqPLovK5kiV6o2SugRtjhNcawToFzzRa2BHYbDaP; GUID="abda4078-3906-d09f-5ff0-11fd3b50d92b"; sessionID=ji13vxb7-i.bzspnkqt73ta7; rssoSessionID=vTehB7chhVqPuMEJjCmqnTOE7ultufddgJ0oiFF/Xe6dAV2VcyI2JH9I/6cqCLms; THDSSO=GVnyCsTJCZaZDBya5CpDrh8RR2S6xGQ8rXOjrxOW9avQ4xB6Q7C9wZimKS77k0uhTKXIS05Snx7rdrmeeOsCNOuNmq8RX5g1yYPTgVpsrCvmWl3Q7RvhBg1Bdiu6BS7uWfbCX4wMSayIWRSg143U4Z6PtC9QuX
 bJhBRuuAJ0zXsfB1YYilLlju6JObTuefOyovIK4Nuq5rrUDsOtaTEpvrxb4Zj0uemAW0BRppZLIwOu1GQETSsad2jmGrHqdh6JlFejKFdRNQxA42lN7WLSq0K9ctjb52Ij71TkwUNnwh9ZwFkYBEIEJr1tYlntMjB4iHBuhGf06TUpajGh4q0BRl92jxUFLL6ZlJP4FpuNH92B2gHyvjxLIW6cm2AKQexKSr4YJqb14m5sqdpTuGfRj6bsaBP8wAtZkQ0yByrEHMEwfy3ARHLYib2lRbCetJC7X0wGwSJVgzkRz3yZ44YMEZpXGmxyvPw6TME1kUyEatLbtUp6gI2EK004q1v8ovQ5UEzEPhrYmjuZG03Y061K9Y3kQ7PFQy7A9vmCATSf6m5oFbJVSi0m0Ao9NQL2ZXclzMyJFmofghSA6vpKa2mnuQKuMTxzfIm79oIsQbC9GUX35MV0Se17GVXQoL8b3Hqy8P1BsIUUc2pz0xlAZz1r6aeUsTvSOUeVMYO9PVvE8lfj6So7DhyysxWDGQCLDU4xqcIwYQWv4Grm3M66cV4oUsRCLZbMAnJeKUDMkO2F5DgpFKVFXHnyryz7AoKPWybQReAqEjyZkM1HG8vXZWCg6JESndIUoVGU0PWHyyaT1wwCQ9XeU6RVoc6h0lxL
HTTP/1.1 302 Found
Date: Tue, 05 Jun 2018 03:09:55 GMT
Server: Apache PivotalWebServer
Set-Cookie: _shibsession_64656661756c7468747470733a2f2f736173636c6f75642e686f6d656465706f742e636f6d2f73686962626f6c657468=_700fc6053a361cc5cb24c8aa6727e665; path=/; HttpOnly
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Cache-Control: private,no-store,no-cache,max-age=0
Location: https://sascloud.<corp>.com/SASLogon/login?service=https%3A%2F%2Fsascloud.<corp>.com%2FSASStudio%2Fj_spring_cas_security_check
Content-Length: 316
Content-Type: text/html; charset=iso-8859-1
Via: 1.1 google
Alt-Svc: clear

SHIBBOLETH ROUTING TO APPLICATION AFTER SUCCESSFUL LOGIN
GET https://sascloud.<corp>.com/SASLogon/login?service=https%3A%2F%2Fsascloud.<corp>.com%2FSASStudio%2Fj_spring_cas_security_check HTTP/1.1
Host: sascloud.<corp>.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://thdsaml-qa.<corp>.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: _vwo_uuid_v2=D4A207004D164465DF5A2C4F65B13EDEF|9cf24f88a390e29700f1e0e362ecf9c9; visid_incap_996692=kMugpANRRt6l+uCwnMjNXb8xe1oAAAAAQUIPAAAAAACauoqucnVwbPXDKk76479Z; _ga=GA1.2.271266464.1517503567; s_vi=[CS]v1|2D38E4C80507DBF8-4000010460003BF0[CE]; LPVID=RlMThhZjk0MDkwN2U0MGFj; _vis_opt_s=1%7C; _vwo_uuid=D070FCAC86C261ED2B3E2B16A15F3CFEF; _vis_opt_exp_2_combi=1; _abck=B5BE87F7A085FBFE166C0FCEA50AA669B81C7F0D071F0000C856E85AF636B675~0~IEOqYPpHT6/zlgy0PesxnKZy7Zg+7hxTnqw2zFDZNkM=~-1~-1; THD_CACHE_NAV_PERSIST=; ftr_ncd=6; thda.u=f9dbcda9-9991-a0c5-c609-9f5a830c0bd4; p_seg=seg1%3D7183005; RES_TRACKINGID=367400434790740; mbox=PC#f3dc3719fdd54d408b332525bcc2cbee.17_41#1588420810|session#d493ed9556874c66970b67f1f6f38759#1525216224; forterToken=d3077b5064204c0d9a466cd3899ff3a6_1525214363690__UDF4_6; s_pers=%20productnum%3D1%7C1527768083263%3B%20s_nr%3D1525214365203-Repeat%7C1556750365203%3B%20s_dslv%3D1525214365207%7C1619822365207%3B%20s_dslv_s%3DLess%2520than%25201%2520day%7C1525216
 165207%3B; THD_PERSIST=C4%3D121%2BCumberland%20-%20Atlanta%2C%20GA%2B%3A%3BC4_EXP%3D1556712013%3A%3BC24%3D30339%3A%3BC24_EXP%3D1556712013%3A%3BC34%3D31.1%3A%3BC34_EXP%3D1525300765%3A%3BC39%3D1%3B8%3A00-20%3A00%3B2%3B6%3A00-22%3A00%3B3%3B6%3A00-22%3A00%3B4%3B6%3A00-22%3A00%3B5%3B6%3A00-22%3A00%3B6%3B6%3A00-22%3A00%3B7%3B6%3A00-22%3A00%3A%3BC39_EXP%3D1525179613; ctm={'pgv':93917700242109|'vst':6587122566013417|'vstr':3865677187556332|'intr':1525214365300|'v':1|'lvst':638}; AMCV_F6421253512D2C100A490D45%40AdobeOrg=-894706358%7CMCAID%7C2D38E4C80507DBF8-4000010460003BF0%7CMCIDTS%7C17653%7CMCMID%7C51736870787950132971209766123311017639%7CMCAAMLH-1525780809%7C7%7CMCAAMB-1525819165%7CRKhpRz8krg2tLO6pguXWp5olkAcUniQYPHaMWWgdJ3xzPWQmdj0y%7CMCOPTOUT-1525221565s%7CNONE%7CMCCIDH%7C353668118%7CvVersion%7C2.3.0; _br_uid_2=uid%3D2211865213621%3Av%3D12.0%3Ats%3D1525176014136%3Ahc%3D4; _4c_=hVNNT9tAEP0r1R44BXtm1%2FsVCVVJgKqVCqLQ9ojs9ZpYOLG16zStUP4743wgCrTkYM%2Fsvpl573nywNZzv2RjlFxyzIThHMSI3fs%2FkY0fm
 OuG56%2FhsQoNG7N533dxnKbr9TqZtwtf%2Bq7tE9cuUpdOuq6p86Xz8fayqnyIbMRcW3oqQ5tkCae8WjVV3TTXfRv851O6obNuFdw8jwPugtLC9zmFbajv6iXls6Z29zd5479vC1ATRQlCS2GkUmKoCO06%2BkCXs3kgUh%2BUHEYRd8Y1cqUylSUoUVOZVJruWlLHftbLkgopDZ7ohm0HymLdD1z%2BkkfHvQ%2BLoYzCy683326nZ5PZ5cUzT%2BI6j%2B6FK0UaY%2Fp01IW2TBHSL9fHPBEJpBEkCiO4MlZaqT9OrqYneLSoyxNiK5TRoI22ElBwS0rAaqWQC4EIqJWwRzlB%2BakwZ9nMkCv6dHpujjOgH0Km6CWm53A0uTo7wcFp%2BpIso6BpHRlKCX37Efs0ud15%2Bw%2B3tnJ%2F7BDvzWKbEfu92ycBoJW0iORdT8tj1BYMhAh1uV8sJoqsVICFoZGlKn1V2RwLV6BVrpS5pfnbfuSA5ICZtYoaDEq29dmrcfB63G5B%2FlPzFkV3YNiHlX%2FBQgKXA6bfY6q8if4FhCKCuKWjvu%2BA7kJ16HT4IxIrS0reAHeHfkR6L4NzM8gAu5eB2ZMM2qWDDqPLovK5kiV6o2SugRtjhNcawToFzzRa2BHYbDaP; GUID="abda4078-3906-d09f-5ff0-11fd3b50d92b"; sessionID=ji13vxb7-i.bzspnkqt73ta7; rssoSessionID=vTehB7chhVqPuMEJjCmqnTOE7ultufddgJ0oiFF/Xe6dAV2VcyI2JH9I/6cqCLms; THDSSO=GVnyCsTJCZaZDBya5CpDrh8RR2S6xGQ8rXOjrxOW9avQ4xB6Q7C9wZimKS77k0uhTKXIS05Snx7rdrmeeOsCNOuNmq8RX5g1yYPTgVpsrCvmWl3Q7RvhBg1Bdiu6BS7uWfbCX4wMSayIWRSg143U4Z6PtC9QuX
 bJhBRuuAJ0zXsfB1YYilLlju6JObTuefOyovIK4Nuq5rrUDsOtaTEpvrxb4Zj0uemAW0BRppZLIwOu1GQETSsad2jmGrHqdh6JlFejKFdRNQxA42lN7WLSq0K9ctjb52Ij71TkwUNnwh9ZwFkYBEIEJr1tYlntMjB4iHBuhGf06TUpajGh4q0BRl92jxUFLL6ZlJP4FpuNH92B2gHyvjxLIW6cm2AKQexKSr4YJqb14m5sqdpTuGfRj6bsaBP8wAtZkQ0yByrEHMEwfy3ARHLYib2lRbCetJC7X0wGwSJVgzkRz3yZ44YMEZpXGmxyvPw6TME1kUyEatLbtUp6gI2EK004q1v8ovQ5UEzEPhrYmjuZG03Y061K9Y3kQ7PFQy7A9vmCATSf6m5oFbJVSi0m0Ao9NQL2ZXclzMyJFmofghSA6vpKa2mnuQKuMTxzfIm79oIsQbC9GUX35MV0Se17GVXQoL8b3Hqy8P1BsIUUc2pz0xlAZz1r6aeUsTvSOUeVMYO9PVvE8lfj6So7DhyysxWDGQCLDU4xqcIwYQWv4Grm3M66cV4oUsRCLZbMAnJeKUDMkO2F5DgpFKVFXHnyryz7AoKPWybQReAqEjyZkM1HG8vXZWCg6JESndIUoVGU0PWHyyaT1wwCQ9XeU6RVoc6h0lxL; _shibsession_64656661756c7468747470733a2f2f736173636c6f75642e686f6d656465706f742e636f6d2f73686962626f6c657468=_700fc6053a361cc5cb24c8aa6727e665
HTTP/1.1 302 Found
Date: Tue, 05 Jun 2018 03:09:55 GMT
Server: Apache PivotalWebServer
Set-Cookie: _shibsession_64656661756c7468747470733a2f2f736173636c6f75642e686f6d656465706f742e636f6d2f73686962626f6c657468=; path=/; HttpOnly; expires=Mon, 01 Jan 2001 00:00:00 GMT
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Cache-Control: private,no-store,no-cache,max-age=0
Location: https://thdsaml-qa.<corp>.com/idp/SSO.saml2?SAMLRequest=hZJbb4IwGIb%2FCuk9FFEUGiFhejETN8lgu9jNUmgdTUqL%2FcoO%2F34iO7hduOvv7fMe0iXQVnYk622j7vih52Cdt1YqIKdDgnqjiKYggCjaciC2JkV2syWB55POaKtrLZGTAXBjhVYrraBvuSm4eRE1v7%2FbJqixtgOCMVCope6Z1%2BiWM95p69W6xUUjqkpLbhsPQOOBHuB8V5TIWR%2FjCEUH8A%2FGNmzI5h7oH5BgHS6KnTdcA%2BRs1gl6omw%2BjRd7OvP3kyj2acVDNg8mizjaR%2FGMDTKAnm8UWKpsggJ%2FErn%2B3PXD0p8SPyZh%2BIic%2FLPolVBMqOfLq1SjCMh1WebuWOSBGziVOApQuhwSkpOxOVv7MpZ%2BTYzSfwaF70GX%2BMxptO3I7RG9WedaivrdyaTUryvDqeUJmiCcjk9%2B%2F4j0Aw%3D%3D&RelayState=ss%3Amem%3A505b0278e4f5e1149d1ea5ba4fa6aaf97d5e58798d9ffdf802470e80911daf4b
Content-Length: 798
Content-Type: text/html; charset=iso-8859-1
Via: 1.1 google
Alt-Svc: clear

KICKED BACK TO SAML/IdP AND BEGIN LOOPING:
GET https://thdsaml-qa.<corp>.com/idp/SSO.saml2?SAMLRequest=hZJbb4IwGIb%2FCuk9FFEUGiFhejETN8lgu9jNUmgdTUqL%2FcoO%2F34iO7hduOvv7fMe0iXQVnYk622j7vih52Cdt1YqIKdDgnqjiKYggCjaciC2JkV2syWB55POaKtrLZGTAXBjhVYrraBvuSm4eRE1v7%2FbJqixtgOCMVCope6Z1%2BiWM95p69W6xUUjqkpLbhsPQOOBHuB8V5TIWR%2FjCEUH8A%2FGNmzI5h7oH5BgHS6KnTdcA%2BRs1gl6omw%2BjRd7OvP3kyj2acVDNg8mizjaR%2FGMDTKAnm8UWKpsggJ%2FErn%2B3PXD0p8SPyZh%2BIic%2FLPolVBMqOfLq1SjCMh1WebuWOSBGziVOApQuhwSkpOxOVv7MpZ%2BTYzSfwaF70GX%2BMxptO3I7RG9WedaivrdyaTUryvDqeUJmiCcjk9%2B%2F4j0Aw%3D%3D&RelayState=ss%3Amem%3A505b0278e4f5e1149d1ea5ba4fa6aaf97d5e58798d9ffdf802470e80911daf4b HTTP/1.1
Host: thdsaml-qa.<corp>.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://thdsaml-qa.<corp>.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: _vwo_uuid_v2=D4A207004D164465DF5A2C4F65B13EDEF|9cf24f88a390e29700f1e0e362ecf9c9; visid_incap_996692=kMugpANRRt6l+uCwnMjNXb8xe1oAAAAAQUIPAAAAAACauoqucnVwbPXDKk76479Z; _ga=GA1.2.271266464.1517503567; s_vi=[CS]v1|2D38E4C80507DBF8-4000010460003BF0[CE]; LPVID=RlMThhZjk0MDkwN2U0MGFj; _vis_opt_s=1%7C; _vwo_uuid=D070FCAC86C261ED2B3E2B16A15F3CFEF; _vis_opt_exp_2_combi=1; _abck=B5BE87F7A085FBFE166C0FCEA50AA669B81C7F0D071F0000C856E85AF636B675~0~IEOqYPpHT6/zlgy0PesxnKZy7Zg+7hxTnqw2zFDZNkM=~-1~-1; THD_CACHE_NAV_PERSIST=; ftr_ncd=6; thda.u=f9dbcda9-9991-a0c5-c609-9f5a830c0bd4; p_seg=seg1%3D7183005; RES_TRACKINGID=367400434790740; mbox=PC#f3dc3719fdd54d408b332525bcc2cbee.17_41#1588420810|session#d493ed9556874c66970b67f1f6f38759#1525216224; forterToken=d3077b5064204c0d9a466cd3899ff3a6_1525214363690__UDF4_6; s_pers=%20productnum%3D1%7C1527768083263%3B%20s_nr%3D1525214365203-Repeat%7C1556750365203%3B%20s_dslv%3D1525214365207%7C1619822365207%3B%20s_dslv_s%3DLess%2520than%25201%2520day%7C1525216
 165207%3B; THD_PERSIST=C4%3D121%2BCumberland%20-%20Atlanta%2C%20GA%2B%3A%3BC4_EXP%3D1556712013%3A%3BC24%3D30339%3A%3BC24_EXP%3D1556712013%3A%3BC34%3D31.1%3A%3BC34_EXP%3D1525300765%3A%3BC39%3D1%3B8%3A00-20%3A00%3B2%3B6%3A00-22%3A00%3B3%3B6%3A00-22%3A00%3B4%3B6%3A00-22%3A00%3B5%3B6%3A00-22%3A00%3B6%3B6%3A00-22%3A00%3B7%3B6%3A00-22%3A00%3A%3BC39_EXP%3D1525179613; ctm={'pgv':93917700242109|'vst':6587122566013417|'vstr':3865677187556332|'intr':1525214365300|'v':1|'lvst':638}; AMCV_F6421253512D2C100A490D45%40AdobeOrg=-894706358%7CMCAID%7C2D38E4C80507DBF8-4000010460003BF0%7CMCIDTS%7C17653%7CMCMID%7C51736870787950132971209766123311017639%7CMCAAMLH-1525780809%7C7%7CMCAAMB-1525819165%7CRKhpRz8krg2tLO6pguXWp5olkAcUniQYPHaMWWgdJ3xzPWQmdj0y%7CMCOPTOUT-1525221565s%7CNONE%7CMCCIDH%7C353668118%7CvVersion%7C2.3.0; _br_uid_2=uid%3D2211865213621%3Av%3D12.0%3Ats%3D1525176014136%3Ahc%3D4; _4c_=hVNNT9tAEP0r1R44BXtm1%2FsVCVVJgKqVCqLQ9ojs9ZpYOLG16zStUP4743wgCrTkYM%2Fsvpl573nywNZzv2RjlFxyzIThHMSI3fs%2FkY0fm
 OuG56%2FhsQoNG7N533dxnKbr9TqZtwtf%2Bq7tE9cuUpdOuq6p86Xz8fayqnyIbMRcW3oqQ5tkCae8WjVV3TTXfRv851O6obNuFdw8jwPugtLC9zmFbajv6iXls6Z29zd5479vC1ATRQlCS2GkUmKoCO06%2BkCXs3kgUh%2BUHEYRd8Y1cqUylSUoUVOZVJruWlLHftbLkgopDZ7ohm0HymLdD1z%2BkkfHvQ%2BLoYzCy683326nZ5PZ5cUzT%2BI6j%2B6FK0UaY%2Fp01IW2TBHSL9fHPBEJpBEkCiO4MlZaqT9OrqYneLSoyxNiK5TRoI22ElBwS0rAaqWQC4EIqJWwRzlB%2BakwZ9nMkCv6dHpujjOgH0Km6CWm53A0uTo7wcFp%2BpIso6BpHRlKCX37Efs0ud15%2Bw%2B3tnJ%2F7BDvzWKbEfu92ycBoJW0iORdT8tj1BYMhAh1uV8sJoqsVICFoZGlKn1V2RwLV6BVrpS5pfnbfuSA5ICZtYoaDEq29dmrcfB63G5B%2FlPzFkV3YNiHlX%2FBQgKXA6bfY6q8if4FhCKCuKWjvu%2BA7kJ16HT4IxIrS0reAHeHfkR6L4NzM8gAu5eB2ZMM2qWDDqPLovK5kiV6o2SugRtjhNcawToFzzRa2BHYbDaP; GUID="abda4078-3906-d09f-5ff0-11fd3b50d92b"; pfidpaid=ad..SecureIDRSA1; JSESSIONID=1ovni8yzw8e1hbw1qtjktha5g; NSC_mc-wt-rb-443-w1-uietbnm=ffffffffaf1a890c45525d5f4f58455e445a4a421577; PF=FyMOrA5wCE5hJTJaQPzUD6tk4wEGnxghPJJC0QVrgLY0; sessionID=ji13vxb7-i.bzspnkqt73ta7; rssoSessionID=vTehB7chhVqPuMEJjCmqnTOE7ultufddgJ0oiFF/Xe6
 dAV2VcyI2JH9I/6cqCLms; THDSSO=GVnyCsTJCZaZDBya5CpDrh8RR2S6xGQ8rXOjrxOW9avQ4xB6Q7C9wZimKS77k0uhTKXIS05Snx7rdrmeeOsCNOuNmq8RX5g1yYPTgVpsrCvmWl3Q7RvhBg1Bdiu6BS7uWfbCX4wMSayIWRSg143U4Z6PtC9QuXbJhBRuuAJ0zXsfB1YYilLlju6JObTuefOyovIK4Nuq5rrUDsOtaTEpvrxb4Zj0uemAW0BRppZLIwOu1GQETSsad2jmGrHqdh6JlFejKFdRNQxA42lN7WLSq0K9ctjb52Ij71TkwUNnwh9ZwFkYBEIEJr1tYlntMjB4iHBuhGf06TUpajGh4q0BRl92jxUFLL6ZlJP4FpuNH92B2gHyvjxLIW6cm2AKQexKSr4YJqb14m5sqdpTuGfRj6bsaBP8wAtZkQ0yByrEHMEwfy3ARHLYib2lRbCetJC7X0wGwSJVgzkRz3yZ44YMEZpXGmxyvPw6TME1kUyEatLbtUp6gI2EK004q1v8ovQ5UEzEPhrYmjuZG03Y061K9Y3kQ7PFQy7A9vmCATSf6m5oFbJVSi0m0Ao9NQL2ZXclzMyJFmofghSA6vpKa2mnuQKuMTxzfIm79oIsQbC9GUX35MV0Se17GVXQoL8b3Hqy8P1BsIUUc2pz0xlAZz1r6aeUsTvSOUeVMYO9PVvE8lfj6So7DhyysxWDGQCLDU4xqcIwYQWv4Grm3M66cV4oUsRCLZbMAnJeKUDMkO2F5DgpFKVFXHnyryz7AoKPWybQReAqEjyZkM1HG8vXZWCg6JESndIUoVGU0PWHyyaT1wwCQ9XeU6RVoc6h0lxL
HTTP/1.1 200 OK
Date: Tue, 05 Jun 2018 03:09:55 GMT
Content-Security-Policy: referrer origin
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 8917
------------------------------------------------------------------
POST https://sascloud.<corp>.com/Shibboleth.sso/SAML2/POST HTTP/1.1
------------------------------------------------------------------
GET https://sascloud.<corp>.com/SASLogon/login?service=https%3A%2F%2Fsascloud.<corp>.com%2FSASStudio%2Fj_spring_cas_security_check HTTP/1.1
------------------------------------------------------------------
GET https://thdsaml-qa.<corp>.com/idp/SSO.saml2?SAMLRequest=hZJbb4IwGIb%2FCum9tKDgaISE6cVM3CTCdrGbpUAdTUqL%2FcoO%2F34iO7hduOvv7fMe0gWwVnY07W2jdvzQc7DOWysV0NMhRr1RVDMQQBVrOVBb0Ty93VDfJbQz2upKS%2BSkANxYodVSK%2BhbbnJuXkTF73ebGDXWdkAxBgaV1H3tNrrlNe%2B0dSvd4rwRZaklt40LoPFA93G2zQvkrI5xhGID%2BAdjm3rINjmwPyBRdzjPt%2B5w9ZGzXsXoqQ73%2FpTN2YxFPJyVwZTM9hGJSOhxj8yDQQbQ87UCy5SNkU%2B8qwkJJyQoyJSSiAbBI3Kyz6LXQtVCPV9epRxFQG%2BKIpuMRR64gVOJowAliyEhPRmbs7UvY9nXxCj5Z1D4HnSBz5xG247eHdHrVaalqN6dVEr9ujScWR4jD%2BFkfPL7RyQf&RelayState=ss%3Amem%3A0a6817ae278ed4294a07e068e351ba220e9567d6a675b7ca20e17af6db1a9509 HTTP/1.1
.
.
.

________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

Cantor, Scott E.
> I have a problem that I can't seem to get past. I have included below my
> configuration, a description of my problem, and the first 7 header entries from
> a fiddler trace showing the behavior.  If anyone could provide direction on how
> to further diagnose or correct this, it would be greatly appreciated....
> If I can provide any other info to aid in solving this problem, please let me
> know.

I've told you twice what the problem probably has to be. I won't spend any more time for free, you're not a paying consortium member, and that's the limit of the help I am willing to provide on list.

The trace demonstrates the cookie the SP cares about it is being sent so the only obvious cause is a client address change invalidating the session, which is not something the trace is going to show. The native log would show that happening. If it's not, then I have no other suggestions. Loops are always something only the person runinng the system can fully debug, it's speculation for anybody else.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Greg Haverkamp
In at least one bit of output you've provided (when Scott originally responded about changing IP addresses), it looked like the client IP was changing across requests.

Look into consistentAddress and checkAddress here: https://wiki.shibboleth.net/confluence/x/zIBC

Greg

On Wed, Jun 6, 2018 at 7:25 AM, Cantor, Scott <[hidden email]> wrote:
> I have a problem that I can't seem to get past. I have included below my
> configuration, a description of my problem, and the first 7 header entries from
> a fiddler trace showing the behavior.  If anyone could provide direction on how
> to further diagnose or correct this, it would be greatly appreciated....
> If I can provide any other info to aid in solving this problem, please let me
> know.

I've told you twice what the problem probably has to be. I won't spend any more time for free, you're not a paying consortium member, and that's the limit of the help I am willing to provide on list.

The trace demonstrates the cookie the SP cares about it is being sent so the only obvious cause is a client address change invalidating the session, which is not something the trace is going to show. The native log would show that happening. If it's not, then I have no other suggestions. Loops are always something only the person runinng the system can fully debug, it's speculation for anybody else.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

O'Quinn, Dennis
In reply to this post by O'Quinn, Dennis
The only thing I can say to that last response is 'Wow'....

Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....

Also, I don't recall addressing my question to you (and I checked).

I had the distinct impression from your previous tone that you had already blown me off.

I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.

Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?

And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.

Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).



________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

Cantor, Scott E.
> Your previous responses were none too clear to a novice who does not know
> this environment and you did not reply to one of my key questions, which may
> have helped me along in the right direction, which was asking for a
> definition/perspective of the word 'client' in one of your earlier responses since
> the 'client' in this environment could be one of several entities depending on
> perspective....

I didn't notice that question at the time or I would have clarified that I was referring to the browser.

As for whether you're a novice or not, no, that is irrelevant to how I'm going to answer questions. If you don't understand the answer, then you can ask a follow up, and if I'd noticed that you had, I'd have answered it. Brevity is a better way to make a question stand out, frankly.

> Also, I don't recall addressing my question to you (and I checked).

And I wasn't speaking for anybody else in my response, but I'm the author of the software and I have spent 15 years answering the vast majority of the questions, so pulling back from that responsibility is a major change and I don't take it lightly.

> I had the distinct impression from your previous tone that you had already
> blown me off.

Telling you that I can't keep helping for free is not blowing you off, it's clarifying what I'm prepared to do or not do because of the position of the project with respect to subsidizing my time on support. Nothing in that response was mean or rude or intended as anything other than statement of fact.

> I was under the impression that I was posting to a user community associated
> with Shibboleth where users could share and grow knowledge together.

Nowhere did I say anything about what anybody else might or might not do, but if you think my time is equivalent to anybody else's, sorry, but it's not. Not on some topics anyway.

> Since you know so much and are apparently so annoyed with other people's
> ignorance (which I have noted on more that one post to other people), why do
> you even respond to these?

I respond because historically I was paid and it was my responsibility to do that, and because whether you like my tone or not, it takes me a limited amount of time to answer a simple question as long as I attach very little importance to whether the other person is happy with a brief answer or not. And I don't.

> And speaking of tone, if you wish to forward this project and have it go
> somewhere, your tone in dealing with others that do not know this software
> (or the IdP/SP/SAML environment) may be something you should think about.

I'm perfectly content with where it's gone, and I'm long past caring what people think about my "tone". I won't bother to answer you in the future if you care about being coddled and not answered.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

O'Quinn, Dennis
Sorry, respectful tone is not coddling...  You are not the experienced person out there, so you are coming across as very full of yourself.

And I was not referring to anything about payment when I referred to suspecting I was being blown off....  I was talking about you tone in your responses.  It had nothing to do with you telling me you would not help me for free.  You telling me that is a pretty direct statement.  Not tone.....



-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, June 6, 2018 3:48 PM
To: Shib Users <[hidden email]>
Subject: [EXTERNAL] RE: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

> Your previous responses were none too clear to a novice who does not
> know this environment and you did not reply to one of my key
> questions, which may have helped me along in the right direction,
> which was asking for a definition/perspective of the word 'client' in
> one of your earlier responses since the 'client' in this environment
> could be one of several entities depending on perspective....

I didn't notice that question at the time or I would have clarified that I was referring to the browser.

As for whether you're a novice or not, no, that is irrelevant to how I'm going to answer questions. If you don't understand the answer, then you can ask a follow up, and if I'd noticed that you had, I'd have answered it. Brevity is a better way to make a question stand out, frankly.

> Also, I don't recall addressing my question to you (and I checked).

And I wasn't speaking for anybody else in my response, but I'm the author of the software and I have spent 15 years answering the vast majority of the questions, so pulling back from that responsibility is a major change and I don't take it lightly.

> I had the distinct impression from your previous tone that you had
> already blown me off.

Telling you that I can't keep helping for free is not blowing you off, it's clarifying what I'm prepared to do or not do because of the position of the project with respect to subsidizing my time on support. Nothing in that response was mean or rude or intended as anything other than statement of fact.

> I was under the impression that I was posting to a user community
> associated with Shibboleth where users could share and grow knowledge together.

Nowhere did I say anything about what anybody else might or might not do, but if you think my time is equivalent to anybody else's, sorry, but it's not. Not on some topics anyway.

> Since you know so much and are apparently so annoyed with other
> people's ignorance (which I have noted on more that one post to other
> people), why do you even respond to these?

I respond because historically I was paid and it was my responsibility to do that, and because whether you like my tone or not, it takes me a limited amount of time to answer a simple question as long as I attach very little importance to whether the other person is happy with a brief answer or not. And I don't.

> And speaking of tone, if you wish to forward this project and have it
> go somewhere, your tone in dealing with others that do not know this
> software (or the IdP/SP/SAML environment) may be something you should think about.

I'm perfectly content with where it's gone, and I'm long past caring what people think about my "tone". I won't bother to answer you in the future if you care about being coddled and not answered.

-- Scott

--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=iQq2ZFAdITZ6PFxyZW6ydlIz2IrFywA_Q16gdZ3_3-0&s=YaTD_aUxB7twy-NzyCY9kE_ieEjpqs7oxtknJw8ys58&e=
To unsubscribe from this list send an email to [hidden email]

________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

John Dennis
In reply to this post by O'Quinn, Dennis
On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:

> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have
the context to evaluate. I believe you're new to the mailing list so you
may not realize Scott is not only the primary author of Shibboleth and
member of the OASIS Technical Committee that defines the SAML standard
but IMHO Scott represents some of the best qualities in an open source
community I've seen in my 30+ years of open source work. For years Scott
has promptly responded with useful help to almost every message on this
list. As a matter of fact I'm significantly impressed Scott has been
able to do this for so long and still get other work done. Only in the
last year have I seen him pull back a bit and only because he is human
and cannot support everyone 24/7 out of the kindness of his heart. I
applaud open source heroes like Scott and everyone involved in the
Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll
appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

O'Quinn, Dennis
Thank you for your response.  I get your loyalty and his dedication.  And yes, I am *brand* new to the community, to Shibboleth, and to IdP/SP/SAML in general.

I have thanked him already (early on) when he responded so quickly to my postings,  and I gathered my issues was way beneath his level of expertise.

However, to talk down to someone, who he doesn't know and in this case is every bit as old as he is, the way he did, and, the way I have seen him do in numerous other replies as I researched before even joining and wasting the user communities time, deserves feedback.

This is *especially* true given that people like me are essentially customers in a sense.

For me, I was joining a user group.  Not Scott's personal support service.  I am fine with terse and short.  I am fine if he gives me what he does and then moves on (which I had thought had already happened).

I re-submitted my question because I had finally found out how to trace and track data and I wanted to put as much information there to make it as easy as I could for someone to assist me.

I was impressed with his initial responsiveness, though, his advice was way over my head at the time and I had no frame of reference to be able to understand what he was saying.  I was trying to come back and ask more, but, I needed to even know what I was asking.

I have already responded to someone else on a private communication about this that his attitude will hurt this project in the long run, and I believe that.

I am obviously not afraid to speak my mind and offer what I feel to be deserved feedback, but, many others are.

They will not come to your group only to have someone imply that they are idiots for not listening to what they are being told, when actually, they are new to the software and do not have enough knowledge or frame of reference against which to apply and make use of the responses.

And then (as I have seen in quite a few responses from Scott specifically), when they come back for clarification or more discussion, it gets even worse.

NOTE: This feedback is meant to be constructive and is not a triggered response.  If you haven't seen the type of responses that I am refereing to, then I would be surprised.  They were all over the place in the Shibboleth user group responses I was getting via my Google searches.

-----Original Message-----
From: John Dennis <[hidden email]>
Sent: Wednesday, June 6, 2018 4:15 PM
To: Shib Users <[hidden email]>; O'Quinn, Dennis <[hidden email]>
Subject: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:

> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have the context to evaluate. I believe you're new to the mailing list so you may not realize Scott is not only the primary author of Shibboleth and member of the OASIS Technical Committee that defines the SAML standard but IMHO Scott represents some of the best qualities in an open source community I've seen in my 30+ years of open source work. For years Scott has promptly responded with useful help to almost every message on this list. As a matter of fact I'm significantly impressed Scott has been able to do this for so long and still get other work done. Only in the last year have I seen him pull back a bit and only because he is human and cannot support everyone 24/7 out of the kindness of his heart. I applaud open source heroes like Scott and everyone involved in the Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis

________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

IAM David Bantz
Dear Dennis O'Quinn, 

Like others I detected your rising level of frustration in this thread. I hesitate to add any stress and lack confidence I can explain anything better than Scott. But let me perhaps foolishly try. 

The issue that seems clear from some of the log messages you shared is that the IP address of the client workstation appears to shift at every interaction. Those entries in the SP logs indicating sessions created and destroyed - like

new session created: ID (_d8a65139b583fb1e0b5382d39c3078d5) IdP (urn:mace:incommon:alaska.edu) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (137.229.6.126) -

are providing, at the end of the log entry, the IP address of the client - not the service, not the IdP, but the client workstation.

That SP session and the cookie in the client browser are tied to that IP address but apparently the very next time the client goes to the service, the SP notices the client IP address does not match the IP address in the cookie, and destroys that session.  

How and why the client workstation keeps presenting different IP addresses is not something the IdP or the SP have any control of, which is why folks on this list aren't able to provide you a recipe of how to correct the problem you are experiencing. 

One alternative in the thread you may have missed is a reference to documentation on configuring the SP to "not care" about changing IP address: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions:
consistentAddress(boolean) (default is true)
  • When true, the SP will remember the IP address used when creating a session and ensure that all subsequent access associated with this session come from the same address. This can help protect against cookie theft and is less likely than the checkAddress setting to block legitimate access.

Apologies in advance if this is unhelpful.

David Bantz
UA OIT IAM

On Wed, Jun 6, 2018 at 1:25 PM, O'Quinn, Dennis <[hidden email]> wrote:
Thank you for your response.  I get your loyalty and his dedication.  And yes, I am *brand* new to the community, to Shibboleth, and to IdP/SP/SAML in general.

I have thanked him already (early on) when he responded so quickly to my postings,  and I gathered my issues was way beneath his level of expertise.

However, to talk down to someone, who he doesn't know and in this case is every bit as old as he is, the way he did, and, the way I have seen him do in numerous other replies as I researched before even joining and wasting the user communities time, deserves feedback.

This is *especially* true given that people like me are essentially customers in a sense.

For me, I was joining a user group.  Not Scott's personal support service.  I am fine with terse and short.  I am fine if he gives me what he does and then moves on (which I had thought had already happened).

I re-submitted my question because I had finally found out how to trace and track data and I wanted to put as much information there to make it as easy as I could for someone to assist me.

I was impressed with his initial responsiveness, though, his advice was way over my head at the time and I had no frame of reference to be able to understand what he was saying.  I was trying to come back and ask more, but, I needed to even know what I was asking.

I have already responded to someone else on a private communication about this that his attitude will hurt this project in the long run, and I believe that.

I am obviously not afraid to speak my mind and offer what I feel to be deserved feedback, but, many others are.

They will not come to your group only to have someone imply that they are idiots for not listening to what they are being told, when actually, they are new to the software and do not have enough knowledge or frame of reference against which to apply and make use of the responses.

And then (as I have seen in quite a few responses from Scott specifically), when they come back for clarification or more discussion, it gets even worse.

NOTE: This feedback is meant to be constructive and is not a triggered response.  If you haven't seen the type of responses that I am refereing to, then I would be surprised.  They were all over the place in the Shibboleth user group responses I was getting via my Google searches.

-----Original Message-----
From: John Dennis <[hidden email]>
Sent: Wednesday, June 6, 2018 4:15 PM
To: Shib Users <[hidden email]>; O'Quinn, Dennis <[hidden email]>
Subject: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:
> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have the context to evaluate. I believe you're new to the mailing list so you may not realize Scott is not only the primary author of Shibboleth and member of the OASIS Technical Committee that defines the SAML standard but IMHO Scott represents some of the best qualities in an open source community I've seen in my 30+ years of open source work. For years Scott has promptly responded with useful help to almost every message on this list. As a matter of fact I'm significantly impressed Scott has been able to do this for so long and still get other work done. Only in the last year have I seen him pull back a bit and only because he is human and cannot support everyone 24/7 out of the kindness of his heart. I applaud open source heroes like Scott and everyone involved in the Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis

________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

O'Quinn, Dennis
David (and everyone else), I really want to thank everyone for their replies.  The consistentAddress setting was indeed the culprit, so I don’t want to waste other’s time in the group.

Also, I have said all I need to say about my feedback to Scott. This is something that I would usually do on a private channel, but since it was already published on the public channel and as I said before, I had seen such comments in many other threads, I felt a public response was warranted.  I hope it is constructive feedback that is given consideration. I did not give it as judgement. I do not feel the need to live up to or down to anyone else’s opinion and I expect no one to do any different with me.  Everyone is in this world to live up to their own expectations and opinion. My point was that it could be hurting the group and *that* is what should be considered. 

Sent from my iPhone

On Jun 6, 2018, at 7:52 PM, IAM David Bantz <[hidden email]> wrote:

Dear Dennis O'Quinn, 

Like others I detected your rising level of frustration in this thread. I hesitate to add any stress and lack confidence I can explain anything better than Scott. But let me perhaps foolishly try. 

The issue that seems clear from some of the log messages you shared is that the IP address of the client workstation appears to shift at every interaction. Those entries in the SP logs indicating sessions created and destroyed - like

new session created: ID (_d8a65139b583fb1e0b5382d39c3078d5) IdP (urn:mace:incommon:alaska.edu) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (137.229.6.126) -

are providing, at the end of the log entry, the IP address of the client - not the service, not the IdP, but the client workstation.

That SP session and the cookie in the client browser are tied to that IP address but apparently the very next time the client goes to the service, the SP notices the client IP address does not match the IP address in the cookie, and destroys that session.  

How and why the client workstation keeps presenting different IP addresses is not something the IdP or the SP have any control of, which is why folks on this list aren't able to provide you a recipe of how to correct the problem you are experiencing. 

One alternative in the thread you may have missed is a reference to documentation on configuring the SP to "not care" about changing IP address: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions:
consistentAddress(boolean) (default is true)
  • When true, the SP will remember the IP address used when creating a session and ensure that all subsequent access associated with this session come from the same address. This can help protect against cookie theft and is less likely than the checkAddress setting to block legitimate access.

Apologies in advance if this is unhelpful.

David Bantz
UA OIT IAM

On Wed, Jun 6, 2018 at 1:25 PM, O'Quinn, Dennis <[hidden email]> wrote:
Thank you for your response.  I get your loyalty and his dedication.  And yes, I am *brand* new to the community, to Shibboleth, and to IdP/SP/SAML in general.

I have thanked him already (early on) when he responded so quickly to my postings,  and I gathered my issues was way beneath his level of expertise.

However, to talk down to someone, who he doesn't know and in this case is every bit as old as he is, the way he did, and, the way I have seen him do in numerous other replies as I researched before even joining and wasting the user communities time, deserves feedback.

This is *especially* true given that people like me are essentially customers in a sense.

For me, I was joining a user group.  Not Scott's personal support service.  I am fine with terse and short.  I am fine if he gives me what he does and then moves on (which I had thought had already happened).

I re-submitted my question because I had finally found out how to trace and track data and I wanted to put as much information there to make it as easy as I could for someone to assist me.

I was impressed with his initial responsiveness, though, his advice was way over my head at the time and I had no frame of reference to be able to understand what he was saying.  I was trying to come back and ask more, but, I needed to even know what I was asking.

I have already responded to someone else on a private communication about this that his attitude will hurt this project in the long run, and I believe that.

I am obviously not afraid to speak my mind and offer what I feel to be deserved feedback, but, many others are.

They will not come to your group only to have someone imply that they are idiots for not listening to what they are being told, when actually, they are new to the software and do not have enough knowledge or frame of reference against which to apply and make use of the responses.

And then (as I have seen in quite a few responses from Scott specifically), when they come back for clarification or more discussion, it gets even worse.

NOTE: This feedback is meant to be constructive and is not a triggered response.  If you haven't seen the type of responses that I am refereing to, then I would be surprised.  They were all over the place in the Shibboleth user group responses I was getting via my Google searches.

-----Original Message-----
From: John Dennis <[hidden email]>
Sent: Wednesday, June 6, 2018 4:15 PM
To: Shib Users <[hidden email]>; O'Quinn, Dennis <[hidden email]>
Subject: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:
> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have the context to evaluate. I believe you're new to the mailing list so you may not realize Scott is not only the primary author of Shibboleth and member of the OASIS Technical Committee that defines the SAML standard but IMHO Scott represents some of the best qualities in an open source community I've seen in my 30+ years of open source work. For years Scott has promptly responded with useful help to almost every message on this list. As a matter of fact I'm significantly impressed Scott has been able to do this for so long and still get other work done. Only in the last year have I seen him pull back a bit and only because he is human and cannot support everyone 24/7 out of the kindness of his heart. I applaud open source heroes like Scott and everyone involved in the Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis

________________________________

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 at
 tachment.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]




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.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Lipscomb, Gary
In reply to this post by IAM David Bantz

<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

 

From: users [mailto:[hidden email]] On Behalf Of O'Quinn, Dennis
Sent: Thursday, 7 June 2018 10:19
To: Shib Users <[hidden email]>
Subject: Re: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

 

David (and everyone else), I really want to thank everyone for their replies.  The consistentAddress setting was indeed the culprit, so I don’t want to waste other’s time in the group.

 

Also, I have said all I need to say about my feedback to Scott. This is something that I would usually do on a private channel, but since it was already published on the public channel and as I said before, I had seen such comments in many other threads, I felt a public response was warranted.  I hope it is constructive feedback that is given consideration. I did not give it as judgement. I do not feel the need to live up to or down to anyone else’s opinion and I expect no one to do any different with me.  Everyone is in this world to live up to their own expectations and opinion. My point was that it could be hurting the group and *that* is what should be considered. 

Sent from my iPhone


On Jun 6, 2018, at 7:52 PM, IAM David Bantz <[hidden email]> wrote:

Dear Dennis O'Quinn, 


Like others I detected your rising level of frustration in this thread. I hesitate to add any stress and lack confidence I can explain anything better than Scott. But let me perhaps foolishly try. 

 

The issue that seems clear from some of the log messages you shared is that the IP address of the client workstation appears to shift at every interaction. Those entries in the SP logs indicating sessions created and destroyed - like

new session created: ID (_d8a65139b583fb1e0b5382d39c3078d5) IdP (urn:mace:incommon:alaska.edu) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (137.229.6.126) -

are providing, at the end of the log entry, the IP address of the client - not the service, not the IdP, but the client workstation.

 

That SP session and the cookie in the client browser are tied to that IP address but apparently the very next time the client goes to the service, the SP notices the client IP address does not match the IP address in the cookie, and destroys that session.  

 

How and why the client workstation keeps presenting different IP addresses is not something the IdP or the SP have any control of, which is why folks on this list aren't able to provide you a recipe of how to correct the problem you are experiencing. 

 

One alternative in the thread you may have missed is a reference to documentation on configuring the SP to "not care" about changing IP address: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions:

consistentAddress(boolean) (default is true)

·  When true, the SP will remember the IP address used when creating a session and ensure that all subsequent access associated with this session come from the same address. This can help protect against cookie theft and is less likely than the checkAddress setting to block legitimate access.

 

Apologies in advance if this is unhelpful.

 

David Bantz

UA OIT IAM

 

On Wed, Jun 6, 2018 at 1:25 PM, O'Quinn, Dennis <[hidden email]> wrote:

Thank you for your response.  I get your loyalty and his dedication.  And yes, I am *brand* new to the community, to Shibboleth, and to IdP/SP/SAML in general.

I have thanked him already (early on) when he responded so quickly to my postings,  and I gathered my issues was way beneath his level of expertise.

However, to talk down to someone, who he doesn't know and in this case is every bit as old as he is, the way he did, and, the way I have seen him do in numerous other replies as I researched before even joining and wasting the user communities time, deserves feedback.

This is *especially* true given that people like me are essentially customers in a sense.

For me, I was joining a user group.  Not Scott's personal support service.  I am fine with terse and short.  I am fine if he gives me what he does and then moves on (which I had thought had already happened).

I re-submitted my question because I had finally found out how to trace and track data and I wanted to put as much information there to make it as easy as I could for someone to assist me.

I was impressed with his initial responsiveness, though, his advice was way over my head at the time and I had no frame of reference to be able to understand what he was saying.  I was trying to come back and ask more, but, I needed to even know what I was asking.

I have already responded to someone else on a private communication about this that his attitude will hurt this project in the long run, and I believe that.

I am obviously not afraid to speak my mind and offer what I feel to be deserved feedback, but, many others are.

They will not come to your group only to have someone imply that they are idiots for not listening to what they are being told, when actually, they are new to the software and do not have enough knowledge or frame of reference against which to apply and make use of the responses.

And then (as I have seen in quite a few responses from Scott specifically), when they come back for clarification or more discussion, it gets even worse.

NOTE: This feedback is meant to be constructive and is not a triggered response.  If you haven't seen the type of responses that I am refereing to, then I would be surprised.  They were all over the place in the Shibboleth user group responses I was getting via my Google searches.

-----Original Message-----
From: John Dennis <[hidden email]>
Sent: Wednesday, June 6, 2018 4:15 PM
To: Shib Users <[hidden email]>; O'Quinn, Dennis <[hidden email]>
Subject: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:
> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have the context to evaluate. I believe you're new to the mailing list so you may not realize Scott is not only the primary author of Shibboleth and member of the OASIS Technical Committee that defines the SAML standard but IMHO Scott represents some of the best qualities in an open source community I've seen in my 30+ years of open source work. For years Scott has promptly responded with useful help to almost every message on this list. As a matter of fact I'm significantly impressed Scott has been able to do this for so long and still get other work done. Only in the last year have I seen him pull back a bit and only because he is human and cannot support everyone 24/7 out of the kindness of his heart. I applaud open source heroes like Scott and everyone involved in the Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis

________________________________

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 at
 tachment.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

 



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.


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

IAM David Bantz
+1

On Wed, Jun 6, 2018 at 4:24 PM, Lipscomb, Gary <[hidden email]> wrote:

<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


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

O'Quinn, Dennis
In reply to this post by Lipscomb, Gary

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 <[hidden email]> On Behalf Of Lipscomb, Gary
Sent: Wednesday, June 6, 2018 8:25 PM
To: Shib Users <[hidden email]>
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

 

From: users [[hidden email]] On Behalf Of O'Quinn, Dennis
Sent: Thursday, 7 June 2018 10:19
To: Shib Users <[hidden email]>
Subject: Re: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

 

David (and everyone else), I really want to thank everyone for their replies.  The consistentAddress setting was indeed the culprit, so I don’t want to waste other’s time in the group.

 

Also, I have said all I need to say about my feedback to Scott. This is something that I would usually do on a private channel, but since it was already published on the public channel and as I said before, I had seen such comments in many other threads, I felt a public response was warranted.  I hope it is constructive feedback that is given consideration. I did not give it as judgement. I do not feel the need to live up to or down to anyone else’s opinion and I expect no one to do any different with me.  Everyone is in this world to live up to their own expectations and opinion. My point was that it could be hurting the group and *that* is what should be considered. 

Sent from my iPhone


On Jun 6, 2018, at 7:52 PM, IAM David Bantz <[hidden email]> wrote:

Dear Dennis O'Quinn, 


Like others I detected your rising level of frustration in this thread. I hesitate to add any stress and lack confidence I can explain anything better than Scott. But let me perhaps foolishly try. 

 

The issue that seems clear from some of the log messages you shared is that the IP address of the client workstation appears to shift at every interaction. Those entries in the SP logs indicating sessions created and destroyed - like

new session created: ID (_d8a65139b583fb1e0b5382d39c3078d5) IdP (urn:mace:incommon:alaska.edu) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (137.229.6.126) -

are providing, at the end of the log entry, the IP address of the client - not the service, not the IdP, but the client workstation.

 

That SP session and the cookie in the client browser are tied to that IP address but apparently the very next time the client goes to the service, the SP notices the client IP address does not match the IP address in the cookie, and destroys that session.  

 

How and why the client workstation keeps presenting different IP addresses is not something the IdP or the SP have any control of, which is why folks on this list aren't able to provide you a recipe of how to correct the problem you are experiencing. 

 

One alternative in the thread you may have missed is a reference to documentation on configuring the SP to "not care" about changing IP address: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions:

consistentAddress(boolean) (default is true)

  • When true, the SP will remember the IP address used when creating a session and ensure that all subsequent access associated with this session come from the same address. This can help protect against cookie theft and is less likely than the checkAddress setting to block legitimate access.

 

Apologies in advance if this is unhelpful.

 

David Bantz

UA OIT IAM

 

On Wed, Jun 6, 2018 at 1:25 PM, O'Quinn, Dennis <[hidden email]> wrote:

Thank you for your response.  I get your loyalty and his dedication.  And yes, I am *brand* new to the community, to Shibboleth, and to IdP/SP/SAML in general.

I have thanked him already (early on) when he responded so quickly to my postings,  and I gathered my issues was way beneath his level of expertise.

However, to talk down to someone, who he doesn't know and in this case is every bit as old as he is, the way he did, and, the way I have seen him do in numerous other replies as I researched before even joining and wasting the user communities time, deserves feedback.

This is *especially* true given that people like me are essentially customers in a sense.

For me, I was joining a user group.  Not Scott's personal support service.  I am fine with terse and short.  I am fine if he gives me what he does and then moves on (which I had thought had already happened).

I re-submitted my question because I had finally found out how to trace and track data and I wanted to put as much information there to make it as easy as I could for someone to assist me.

I was impressed with his initial responsiveness, though, his advice was way over my head at the time and I had no frame of reference to be able to understand what he was saying.  I was trying to come back and ask more, but, I needed to even know what I was asking.

I have already responded to someone else on a private communication about this that his attitude will hurt this project in the long run, and I believe that.

I am obviously not afraid to speak my mind and offer what I feel to be deserved feedback, but, many others are.

They will not come to your group only to have someone imply that they are idiots for not listening to what they are being told, when actually, they are new to the software and do not have enough knowledge or frame of reference against which to apply and make use of the responses.

And then (as I have seen in quite a few responses from Scott specifically), when they come back for clarification or more discussion, it gets even worse.

NOTE: This feedback is meant to be constructive and is not a triggered response.  If you haven't seen the type of responses that I am refereing to, then I would be surprised.  They were all over the place in the Shibboleth user group responses I was getting via my Google searches.

-----Original Message-----
From: John Dennis <[hidden email]>
Sent: Wednesday, June 6, 2018 4:15 PM
To: Shib Users <[hidden email]>; O'Quinn, Dennis <[hidden email]>
Subject: [EXTERNAL] Re: Problem implementing Shibboleth/SAML to authenticate users for Statistical Analysis Systems (SAS)

On 06/06/2018 03:24 PM, O'Quinn, Dennis wrote:
> The only thing I can say to that last response is 'Wow'....
>
> Your previous responses were none too clear to a novice who does not know this environment and you did not reply to one of my key questions, which may have helped me along in the right direction, which was asking for a definition/perspective of the word 'client' in one of your earlier responses since the 'client' in this environment could be one of several entities depending on perspective....
>
> Also, I don't recall addressing my question to you (and I checked).
>
> I had the distinct impression from your previous tone that you had already blown me off.
>
> I was under the impression that I was posting to a user community associated with Shibboleth where users could share and grow knowledge together.
>
> Since you know so much and are apparently so annoyed with other people's ignorance (which I have noted on more that one post to other people), why do you even respond to these?
>
> And speaking of tone, if you wish to forward this project and have it go somewhere, your tone in dealing with others that do not know this software (or the IdP/SP/SAML environment) may be something you should think about.
>
> Otherwise, your user community will just say screw it and use something else (as I would if I weren't already so deep into it).

We all make mistakes from time to time and sometimes we just don't have the context to evaluate. I believe you're new to the mailing list so you may not realize Scott is not only the primary author of Shibboleth and member of the OASIS Technical Committee that defines the SAML standard but IMHO Scott represents some of the best qualities in an open source community I've seen in my 30+ years of open source work. For years Scott has promptly responded with useful help to almost every message on this list. As a matter of fact I'm significantly impressed Scott has been able to do this for so long and still get other work done. Only in the last year have I seen him pull back a bit and only because he is human and cannot support everyone 24/7 out of the kindness of his heart. I applaud open source heroes like Scott and everyone involved in the Shibboleth project. I'm impressed.

If you spend a bit of time in other open source communities you'll appreciate how good the Shibboleth community is in comparison.

Kudos to everyone involved.


--
John Dennis

________________________________

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 at
 tachment.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 

 



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.




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.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [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 <[hidden email]> On Behalf Of Lipscomb, Gary
Sent: Wednesday, June 6, 2018 8:25 PM
To: Shib Users <[hidden email]>
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.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
> 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.

That's the norm for any LB doing HTTP proxying, which is the most common form of web LB. At the risk of pissing you off again...

If you have a reverse proxy fronting one server with another, no matter how many layers deep, somewhere the SP is going to access REMOTE_ADDR and bind its sessions to that address. It is necessary to maintain that address' fidelity from the client all the way through all the proxies to whereever the SP runs by using Forwarded-For headers to carry it along until it gets where it's going, and Apache there has to be configured to recognize it. Then it all works at least on that score.

If you don't, then either all the traffic comes from one address and it "works" or you have to turn off address binding and it "works", and you've just compromised a primary security check unless you're among the people who think spoofing addresses is really easy (it may be, but I have not been convinced of that).

I did not follow most of the rest of that description of the application but there's only one server involved as far as the SP is concerned and anything else going on is out of scope. The SP doesn't protect server A if you install it on server B, it only protects server B and the applications on B. If you're hopping between servers, there is no cookie shared between them or session of any kind, because the session with A can only ever be seen by A, not B. That’s assuming A and B are not in a proxy relationship.

Anyway, an address issue is basically always about proxying or NAT, either close to the server or more rarely at the client end. With a corporate network it's much messier and more prone to address complications and if both ends are doing it, it's a mess to deal with.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]