locked
SSO Logout issue RRS feed

  • Question

  • Hi,

    We have a solution in production that uses ADFS 2.0 and intergrated with our client who is using the Tivoli Stack.  Federating in from our client's site (using IDP initiated SSO link) work fine but the the user logs out on our end (which is supposed to kill RP tokens and cookies), we occasionally get the following exception from ADFS

     

    An error occurred during processing of the SAML logout request.

    Additional Data

    Caller identity:

    Logout initiator identity:

    Error message: MSIS1012: Unsolicited SAML Logout Response received.

    Exception details:

    User Action

    Ensure that the single logout service is configured properly for this relying party trust or claims provider trust in the AD FS configuration database.

    I searched the web trying to find a similar posting but can't find anything.  Does anybody have any input into this?

    Thanks

    Monday, October 4, 2010 7:37 PM

All replies

  • Hi Isam,

    Are you calling wa=wsignout?

    Regards,

    Mylo

    Tuesday, October 5, 2010 8:51 PM
  • Hello,

    I am working on this with Isam so I can answer...and appreciate your help, thanks!

    Yes, we issue call ADFS signout like this:

    GET /adfs/ls/?wa=wsignout1.0&wreply=https://SomeApp.MyCompany.com HTTP/1.1

    ADFS sends a SAML logout Request to the IDP's single logout URL (defined in the metadata) and it redirects the user back to our /adfs/ls point with a SAML Response with a status of SUCCESS. The response back to the AD FS looks like this:

     

    <

     

    samlp:LogoutResponse xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination=https://adfs.MyCompany.com/adfs/ls/ ID="FIMRSP_7d917f0d-012b-18c6-a2cc-ef4355797fd6" InResponseTo="_96c1abc4-a970-4a3b-a316-5f6b116eda62" IssueInstant="2010-10-05T18:05:08Z" Version="2.0">

    <

     

    saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://security.TheIDPCompany.com/FIM/sps/TheIDP/saml20</saml:Issuer>

    <

     

    ds:Signature Id="uuid7d917f0e-012b-158d-b4d9-ef4355797fd6">

    <

     

    ds:SignedInfo>

    <

     

    ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>

    <

     

    ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod>

    <

     

    ds:Reference URI="#FIMRSP_7d917f0d-012b-18c6-a2cc-ef4355797fd6">

    <

     

    ds:Transforms>

    <

     

    ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>

    <

     

    ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

    <

     

    xc14n:InclusiveNamespaces xmlns:xc14n="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds samlp saml"></xc14n:InclusiveNamespaces>

    </

     

    ds:Transform>

    </

     

    ds:Transforms>

    <

     

    ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>

    <

     

    ds:DigestValue>54XS+MmwURWS5+IG0939Oscw9xw=</ds:DigestValue>

    </

     

    ds:Reference>

    </

     

    ds:SignedInfo>

    <

     

    ds:SignatureValue>crZrOIvaHqheMmyw3dCsrQOem9z+zAx7BgL+zOQC3IpYBgrdMxO9BJ9av0AdUBMdk77MH8EmXYuqdHmvPDQBd/LQYg+OAmyGp29M5tt5uIgVO3WuheYnTz+JvKYWYBcweGoWOiGVvTWZm7CPwHhJOTAOtak2CPN2zt53trFX9Qs=</ds:SignatureValue>

    <

     

    ds:KeyInfo>

    <

     

    ds:X509Data>

    <

     

    ds:X509Certificate>MIICBzCCAXCgAwIBAgIEQH26vjANBgkqhkiG9w0BAQQFADBIMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGVGl2b2xpMQ4wDAYDVQQLEwVUQU1lQjEYMBYGA1UEAxMPZmltZGVtby5pYm0uY29tMB4XDTA0MDQxNDIyMjcxMFoXDTE3MTIyMjIyMjcxMFowSDELMAkGA1UEBhMCVVMxDzANBgNVBAoTBlRpdm9saTEOMAwGA1UECxMFVEFNZUIxGDAWBgNVBAMTD2ZpbWRlbW8uaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAiZ0D1X6rk8+ZwNBTVZt7C85m421a8A52Ksjw40t+jNvbLYDp/W66AMMYD7rB5qgniZ5K1p9W8ivM9WbPxc2u/60tFPg0e/Q/r/fxegW1K1umnay+5MaUvN3p4XUCRrfg79OvurvXQ7GZa1/wOp5vBIdXzg6i9CVAqL29JGi6GYUCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBXiAhxm91I4m+g3YX+dyGc352TSKO8HvAIBkHHFFwIkzhNgO+zLhxg5UMkOg12X9ucW7leZ1IB0Z6+JXBrXIWmU3UPum+QxmlaE0OG9zhp9LEfzsE5+ff+7XpS0wpJklY6c+cqHj4aTGfOhSE6u7BLdI26cZNdzxdhikBMZPgdyQ==</ds:X509Certificate>

    </

     

    ds:X509Data>

    </

     

    ds:KeyInfo>

    </

     

    ds:Signature>

    <

     

    samlp:Status>

    <

     

    samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></samlp:StatusCode>

    </

     

    samlp:Status>

    </

     

    samlp:LogoutResponse>

    Note that this is an AD FS farm of 2 servers, behind AD FS proxies.

    It does not happen all the time.


    Allen Conant
    Tuesday, October 5, 2010 10:25 PM