windows SP looping

Tue Oct 10 19:41:40 EDT 2017

I’m having a problem with setting up my first Windows SP. The IdP has been in service for several years. I can call a service on the SP (called “secure”) and I see it redirect properly to the IdP. I can successfully enter my Network ID and password. And I see that the IdP correctly sends assertions to the SP. But when it returns from the IdP back to the SP it wants to start a whole new session again.  Ending up in an endless loop. I’ve searched the archives and didn’t find any solutions that worked for me.

My environment:

* A pair of linux IdPs behind a load balancer
* A single Windows SP behind a load balancer (in the future I’ll have a pair)

Calling “Shibboleth.sso\Status” and running “shibd.exe –check” both are good.

One thing I find odd is that all traffic from the loadbalancer to the SP comes to the SP as one IP address (Eg 192.1.2.3)
which is the load balancer. Which is to say, a client who is 10.4.5.6 gets changed to 192.1.2.3 when it arrives at the SP.
Likewise, if the IdP is 134.2.3.4 when redirected back to the SP it also shows up as 192.1.2.3. I know that’s just
the way the load balancer is setup. Could this be a problem?

Here is my shibboleth2.xml:

<SPConfig
    clockSkew="180">
    <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true" safeHeaderNames="false">
            <Site id="1" name="dev-sp.it.wsu.edu" scheme="https" port="443"/>
        </ISAPI>
    </InProcess>
    <RequestMapper type="Native">
        <RequestMap>
            <Host name="dev-sp.it.wsu.edu" redirectToSSL="443">
                        <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
       </RequestMap>
    </RequestMapper>
    <ApplicationDefaults entityID="https://dev-sp.it.wsu.edu/"
                         REMOTE_USER="employeeNumber uid "
                         cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2">
            <Sessions lifetime="32400" timeout="32400" checkAddress="false"
                        consistentAddress="true" relayState="ss:mem" handlerSSL="true"
                        postData="ss:mem" postTemplate="postTemplate.html"
                        cookieProps="; HttpOnly path=/; secure">
            <SSO entityID="https://dev-idp.it.wsu.edu/idp/shibboleth"
                        discoveryProtocol="SAMLDS"
                        discoveryURL="https://dev-idp.it.wsu.edu/DS/WAYF"<https://dev-idp.it.wsu.edu/DS/WAYF%22>>
                        SAML2 SAML1
            </SSO>
            <Logout>SAML2 Local</Logout>
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1  192.1.2.3"/>
            <Handler type="Session" Location="/Session" showAttributeValues="true"/>
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
        </Sessions>
            <MetadataProvider type="XML"
                        uri="https://dev-idp.it.wsu.edu/idp/profile/Metadata/SAML"
                        backingFilePath="dev-dp.it.wsu.edu.metadata.xml" reloadInterval="7200">
        </MetadataProvider>
        <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
        <AttributeResolver type="Query" subjectMatch="true"/>
        <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
        <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
    </ApplicationDefaults>
    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>

Now I’ll show what I see in the logs (I added DEBUG).

From the transaction log there is a new session:

2017-10-06 15:08:24 INFO Shibboleth-TRANSACTION [1]: New session (ID: _2e2ff5942eee70e545d547a17f10cb68) with (applicationId: default) for principal from (IdP: https://dev-idp.it.wsu.edu/idp/shibboleth) at (ClientAddress: 192.1.2.3) with (NameIdentifier: _c903d65316185de5601c9ab64d457efd) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: _fe90e6343940bf111acce98d9ad7f116)

Then in the shibd.log you can see this session inserted (I’ve removed a lot of the chatter, hopefully not too much):

2017-10-06 15:08:24 DEBUG Shibboleth.SessionCache [1]: creating new session
2017-10-06 15:08:24 DEBUG Shibboleth.SessionCache [1]: storing new session...
2017-10-06 15:08:24 DEBUG XMLTooling.StorageService [1]: inserted record (session) in context (_2e2ff5942eee70e545d547a17f10cb68) with expiration (1507360104)
2017-10-06 15:08:24 INFO Shibboleth.SessionCache [1]: new session created: ID (_2e2ff5942eee70e545d547a17f10cb68) IdP (https://dev-idp.it.wsu.edu/idp/shibboleth) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (192.1.2.3)

2017-10-06 15:08:24 DEBUG Shibboleth.SSO.SAML2 [1]: ACS returning via redirect to: https://dev-sp.it.wsu.edu/secure

2017-10-06 15:08:24 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://dev-sp.it.wsu.edu/Shibboleth.sso/SAML2/POST" Destination="https://dev-idp.it.wsu.edu/idp/profile/SAML2/Redirect/SSO" ID="_b73b7072cd5f9b9fc36c7dfb20be730a" IssueInstant="2017-10-06T22:08:24Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://dev-sp.it.wsu.edu/</saml:Issuer><samlp:NameIDPolicy<https://dev-sp.it.wsu.edu/%3c/saml:Issuer%3e%3csamlp:NameIDPolicy> AllowCreate="1"/></samlp:AuthnRequest>

.
.
.
2017-10-06 15:08:25 DEBUG Shibboleth.SSO.SAML2 [1]: SSO profile processing completed successfully
2017-10-06 15:08:25 DEBUG Shibboleth.SSO.SAML2 [1]: extracting pushed attributes...
2017-10-06 15:08:25 DEBUG Shibboleth.AttributeFilter [1]: filtering 4 attribute(s) from (https://dev-idp.it.wsu.edu/idp/shibboleth)
2017-10-06 15:08:25 DEBUG Shibboleth.SSO.SAML2 [1]: resolving attributes...

So I can see that the IdP successfully passed assertions back to the SP like expected.
And for some reason, it starts a new session all over and does not continue with the above session:

2017-10-06 15:08:25 DEBUG Shibboleth.SessionCache [1]: creating new session
2017-10-06 15:08:25 DEBUG Shibboleth.SessionCache [1]: storing new session...
2017-10-06 15:08:25 DEBUG XMLTooling.StorageService [1]: inserted record (session) in context (_b3dbbf5e504b36cef0054c707e8bc8d1) with expiration (1507360105)
2017-10-06 15:08:25 DEBUG XMLTooling.StorageService [1]: updated record (_c903d65316185de5601c9ab64d457efd) in context (NameID) with expiration (1507360105)
2017-10-06 15:08:25 DEBUG XMLTooling.StorageService [1]: inserted record (_8844a118fbbdbe128b0e39ade4695f66) in context (_b3dbbf5e504b36cef0054c707e8bc8d1) with expiration (1507360105)
2017-10-06 15:08:25 INFO Shibboleth.SessionCache [1]: new session created: ID (_b3dbbf5e504b36cef0054c707e8bc8d1) IdP (https://dev-idp.it.wsu.edu/idp/shibboleth) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (192.1.2.3)
2017-10-06 15:08:25 DEBUG XMLTooling.StorageService [1]: deleted record (43c735b0c32fdead9da3eb39252dafec58b691d04cfda9bcb84b0fc8e651e433) in context (RelayState)

And sure enough, the transaction log also shows a new session:
And the process loops over and over and over ….

I’ve tried various suggestions in the archives related to looping, but I haven’t found the right answer yet.

thanks – Dean

Dean Guenther                          dean.guenther at wsu.edu<mailto:dean.guenther at wsu.edu>
Washington State University    Phone:    509 335-0433
Pullman, WA. 99164-1222        fax:      509 335-0540
Identity and Access Management Manager

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171010/a5e4623b/attachment-0001.html>