windows SP looping
Chris Andre
candre at overtsoftware.com
Wed Oct 11 04:11:25 EDT 2017
Hello Dean,
The main time I have seen this its been due to the fact that the URL that
is protected with shibboleth i.e dev-sp.it.wsu.edu/secure isn't being
accessed over https. For example users are going to
http://dev-sp.it.wsu.edu/secure instead of https://dev-sp.it.wsu.edu/secure.
So first thing to check would be that your accessing the site over https
for the location that is protected by shibboleth.
As an aside it maybe easier to just set your cookieprops to https so
i.e: cookieProps="https" if your using V2.5+
Not sure if you have seen this page here that goes over some more common
issues with SP Looping:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLooping
Thanks
Kindest Regards
Chris
On 11 October 2017 at 00:41, Guenther, Dean R. <guenther at wsu.edu> wrote:
> 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">
>
> 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 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
> Washington State University Phone: 509 335-0433 <(509)%20335-0433>
> Pullman, WA. 99164-1222 fax: 509 335-0540 <(509)%20335-0540>
> Identity and Access Management Manager
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
--
--
Chris Andre
CTO, Overt Software Solutions Ltd
For support queries please email support at overtsoftware.com to ensure that
your query is sent to all available engineers.
Cloud Hosting / Dedicated Servers | Shibboleth | Moodle | Cloud backups &
file sharing
Checkout our Shibboleth Self Heal Webinar here
https://www.overtsoftware.com/webinars/
T: 0330 2000 141 | E: candre at overtsoftware.com | www.overtsoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171011/2901cbb0/attachment-0001.html>
More information about the users
mailing list