How to implement single logout using okta as IDP? - logout

In Okta developer account I have enabled the SAML Single Logout and get Identity Provider Single Logout URL. I have created following logout request using NameID and SessionIndex obtained from SAML response that we get during single sign-on process.
Logout Request :
<?xml version="1.0" encoding="UTF-8"?>
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://dev-6#####.oktapreview.com/app/nepasoftdev660864_spdemo_1/exk606bnr5BZOBF7z0h7/slo/saml" ID="_b2be5dbd-928a-4554-a879-25a179e36ee2" IssueInstant="2016-03-25T10:20:47Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://192.###.###.##/spdemo</saml:Issuer>
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">ramesh.shrestha#nepasoft.com</saml:NameID>
<samlp:SessionIndex>id1458901238038.94596883</samlp:SessionIndex>
</samlp:LogoutRequest>
I am getting the following Logout Response with status code RequestDenied
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://localhost:10262/Logout.aspx" ID="id1846510753301801884197562" InResponseTo="_b2be5dbd-928a-4554-a879-25a179e36ee2" IssueInstant="2016-03-25T10:22:40.389Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://192.###.###.##/spdemo</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#id1846510753301801884197562">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>LQwvto+ERXvrQRUB7LOUUznSXII=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>P+T1K.....ZYvCw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIID.....7zK0rH</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</saml2p:Status>
</saml2p:LogoutResponse>
Why might be the reason for getting RequestDenied status? Did i missed something on logout request or misconfigured during enabling single logout in Okta?
Thanks in advanced.

You also need to sign the LogoutRequest so you would need to include a Signature element (similar to what you are getting back in the LogoutResponse).
That said, I'm running into the same issue you are. I have signed my LogoutRequest but am still getting a LogoutResponse with status RequestDenied.
I did find this thread (https://support.okta.com/help/answers?id=906F0000000I07YIAS) on Okta's support page which indicates that the HTTP-Redirect binding is not supported for logout so you may need to you HTTP-Post. I've not tried that yet.

Related

ADFS 2012 response is not returning Name ID

My application is sending a SAML request to ADFS, which prompts me to log in to the AD, and my application is getting a SAML response back. However, it does not contain a Name ID.
In the Claims rules I set up these two:
Send LDAP Attributes as Claims
LDAP Attribute: E-Mail-Addresses
Outgoing Claim Type: E-Mail Address
Attribute Store: Active Directory
Transform an Incoming Claim
Incoming Claim Type: E-Mail Address
Outgoing Claim Type: Name ID
Outgoing Name ID Format: Email
Pass through all claim values
I assume that when I am prompted to enter my email address, that this email address is added to the incoming claim?
Why isn't it transforming it and sending it back? I think there should be a "NameID" node in the Subject?
Response XML:
<samlp:Response ID="_e7eae5c5-abf6-4f8f-a869-95ecc373410a" Version="2.0" IssueInstant="2023-01-16T15:55:47.323Z" Destination="https://localhost:8443/rrdefenceweb/services/ui/authenticateSaml" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="iddd342818-ac09-40cc-9c79-12e61dab8165"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.adfstest.com/adfs/services/trust
</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_196d47b3-d764-4a73-a136-2cd8cbd2a905" IssueInstant="2023-01-16T15:55:47.323Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://adfs.adfstest.com/adfs/services/trust</Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_196d47b3-d764-4a73-a136-2cd8cbd2a905">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>Y2uhE7CuNU4iI4r8N6nRMGhzV8icSjUrxrInhXZzFoQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>JVE8Pk2CDVmIoXCLxr1zITlOaOublJY5nwF9kxBA+T80KYI97N36DwcGIN2pJN4KjPbQfR/LHHXVXmaEzBoA5kZ2Bii3r49qlDWi1eujfDL8lY/GLiUNuZCALRqPpS2f6TKeKucECQVgqE5WMVHeULjLBOQI41alEfHqnGVABQLoKhB8LSBeJU2f65hapKG0Q2ffmr+BunxH+Srfz5oBF+pScQwtsrP/Kr4SD4DvmLz/xCEyKNqzaDT+WNwZ9MN2Rjtx3hOiS/YBjJ9CqUYGdxAglEg7yu3uzQ4UsqM4MlZSBY5lPtTa16qYSwq2NgM6sQrMAo5BVsLz3kIfJlulOg==</ds:SignatureValue>
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIC3jCCAcagAwIBAgIQRiRqmG8/OKBIVDkoSvTPcDANBgkqhkiG9w0BAQsFADArMSkwJwYDVQQDEyBBREZTIFNpZ25pbmcgLSBhZGZzLmFkZnN0ZXN0LmNvbTAeFw0yMzAxMDkxODQ1MzdaFw0yNDAxMDkxODQ1MzdaMCsxKTAnBgNVBAMTIEFERlMgU2lnbmluZyAtIGFkZnMuYWRmc3Rlc3QuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/C6v11/9nwR6JpY2Q0H+Q/DE4jXi7y7h/KXdlBS/ktnCUoesRcgmyTdzoU0+DK7hZXZ+V4qk2KYYcRlikiL9nGkLkA+wIIAdrKLZzraD+H+TCAYLyVY21oUGUg2oD8WqibwtutJejX+9ATJ9xCBu+xX2VDXUmQEyTqNYIj98/XAiob+eQbCfDQuoadLRo5UfM/9jOaRUHmVo9xdP58d7egKpSfhungYA3Kilc6Lu38QywnxYQlq2KpZ67SJr3cuERc1wOUzTcgKcVdvv+sUBQ5uj01SYAUX+snhgjr8/w9+13AVoTiyTbEmjW+lK3e26Rb4QQ2P/ZGmGpIz3hLyMAQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCtQ+9sAWwPJmNN6TUEqqUV068u98Yk22cNqrwKx3HMrZKcj2jBQ5+4zCzYtPRt4dToapYeWIsMVasb4yQ+BT7y8dPaeHRezCUwvRpDGBroQYL0BFVyxE1P4tM7OZR5bV+zGMT857Nvm+0uSHzMJGrjGFa91ZgazDAEdIgQ96x/I48CrftPzhUkLWZgW2xNv1Z4DdgO7ImjvB49dNQuwv0aiZOiL2xuPj/FcQpqklu/VL3aKFiS4TL0cPEdJVE7KHtkBqT6Uje4xuWBAXHOfKCJ6gIbE9I9WyQ6bPSRNqDhQV9povM56Yob8g7Nhva/486Xd4kwzm6gzh4M24LywZgW</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="iddd342818-ac09-40cc-9c79-12e61dab8165" NotOnOrAfter="2023-01-16T16:00:47.323Z" Recipient="https://localhost:8443/rrdefenceweb/services/ui/authenticateSaml" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2023-01-16T15:55:47.323Z" NotOnOrAfter="2023-01-16T16:55:47.323Z">
<AudienceRestriction>
<Audience>https://localhost:8443/rrdefenceweb</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2023-01-16T10:53:40.791Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
Federation XML:
https://adfs.adfstest.com/federationmetadata/2007-06/federationmetadata.xml
It was because in the Active Directory, my user did not have an Email Address set (even though my login name was in an email format, it is a separate field that needs setting).
Answer worked out thanks to this:
Why is ADFS not returning an email claim?

Does OneLogin SAML Authn Request Signature Validation Tool Support HTTP-POST Binding?

I am talking about https://www.samltool.com/validate_authn_req.php . In our case, we use embedded signature value in Authn request xml. Looks like it doesn't work as our ProtocolBinding is HTTP-POST.
For example lets take this sample xml,
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="pfx41d8ef22-e612-8c50-9960-1b16f15741b3" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
<saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#pfx41d8ef22-e612-8c50-9960-1b16f15741b3">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>yJN6cXUwQxTmMEsPesBP2NkqYFI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>g5eM9yPnKsmmE/Kh2qS7nfK8HoF6yHrAdNQxh70kh8pRI4KaNbYNOL9sF8F57Yd+jO6iNga8nnbwhbATKGXIZOJJSugXGAMRyZsj/rqngwTJk5KmujbqouR1SLFsbo7Iuwze933EgefBbAE4JRI7V2aD9YgmB3socPqAi2Qf97E=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQQFADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcwMDI5MjdaFw0xNTA3MTcwMDI5MjdaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vU/6R/OBA6BKsZH4L2bIQ2cqBO7/aMfPjUPJPSn59d/f0aRqSC58YYrPuQODydUABiCknOn9yV0fEYm4bNvfjroTEd8bDlqo5oAXAUAI8XHPppJNz7pxbhZW0u35q45PJzGM9nCv9bglDQYJLby1ZUdHsSiDIpMbGgf/ZrxqawIDAQABo1AwTjAdBgNVHQ4EFgQU3s2NEpYx7wH6bq7xJFKa46jBDf4wHwYDVR0jBBgwFoAU3s2NEpYx7wH6bq7xJFKa46jBDf4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQCPsNO2FG+zmk5miXEswAs30E14rBJpe/64FBpM1rPzOleexvMgZlr0/smF3P5TWb7H8Fy5kEiByxMjaQmml/nQx6qgVVzdhaTANpIE1ywEzVJlhdvw4hmRuEKYqTaFMLez0sRL79LUeDxPWw7Mj9FkpRYT+kAGiFomHop1nErV6Q==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
I am using ds:SignatureValue value that would go into Signature of the SAML AuthN Request box. Also I have mentioned proper cert in "X.509 cert of the Service Provider". But it always returns "Signature validation failed. AuthN Request rejected". I can see "Paste the AuthN Request if you want to also validate its signature (HTTP-Redirect binding)" mentioned in the page.
So I am wondering if this validation tool only works for HTTP-Redirect binding & not for HTTP-POST binding. Otherwise, we will have to check from our side & we don't see any issues as of now.

Getting Error while trying to access nextcloud through sso

I have problems with SAMLRequest not being authenticated by nextcloud
<samlp:Response ID="_7b0ef094-ae04-4d2c-a7d1-e9d5e698c278"
Version="2.0"
IssueInstant="2019-05-28T12:19:07.704Z"
Destination="https://192.168.1.136/index.php/apps/user_saml/saml/acs"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WindowsServer19.server.net/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>
<Assertion ID="_3acf9e24-2f34-47bf-82fb-97f6d11ab652"
IssueInstant="2019-05-28T12:19:07.703Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://WindowsServer19.server.net/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_3acf9e24-2f34-47bf-82fb-97f6d11ab652">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>0frZvK2y9o8WTDfpB3rBlK+82W4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
s4NAgv4ucV5xM6Ig+GsNunpNo5whkJljUec9KtNh00UbRZJ3q2KdzNQ3ZxhpvYudTDqlgzwnenaPmZIcpmgzuqaIiHTStBWUgafZDljZ4/WnQ8SRslMBgRNtuh3NU8qh+0Hgr3k+ngZc1YvlACy+sPeoBxZoFKTC+cwXVeezdlTnPW+IbZ2T1xeLmjz42oelqrnGbsnu6btNgTHzij302YCsbnlKe6wAEw9CvjFCtWPW1dV9iL6FLYkJfPporG9D7FkW+nZoYa8SHns8VRFM97sBKSBcX/csneJiX+7b+hZttw+MPsXmXBgXiU8D0boRjqKByv51fhlhLpKl3HRZZg==
</ds:SignatureValue>
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIC8DCCAdigAwIBAgIQMCGuwW//8oZPRuZYDplwVTANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylBREZTIFNpZ25pbmcgLSBXaW5kb3dzU2VydmVyMTkuc2VydmVyLm5ldDAeFw0xOTA1MjMwMTM1MjJaFw0yMDA1MjIwMTM1MjJaMDQxMjAwBgNVBAMTKUFERlMgU2lnbmluZyAtIFdpbmRvd3NTZXJ2ZXIxOS5zZXJ2ZXIubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7VQR25k7qgmSYMhh40HYEdaki0Itff0QfjpABaNLJJYLB51ikpK/PctqXDy2StJqo4ai3wcrM2xjcLKm7pOGpNYYF2Brdf8ae3i+gjh3Ej6vDYWs/YWve2yZarBkUxTSFlCLsUACIu5nuo7JmVU9ptPcmcKqEZamU1U04qt6RJzxKvLOdFa4nT2Nx1jM8lGyo+x4oJ0agaSORURdQQVSfIJMUuEXWufp0qeCRt3KrQHf6NzJYGvDCdF6bu5lsrXma+nEIxvs88qg7P15ntA+HTdxut3M9vLm+P2nvZMfxU+BKScBWpBfKDAkABF3PibCjnlr0pJ0ZUwPGsya180NAQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAl1f4+rQ3jG+8TfTNtnT/VX8DgXLCop8yrypU/i5AHeS9Xwmi2vqPwEkJQLd84ictIVU43NxtQPvj9RT6IjrwSaDqQcwVOcL0ectlp4cy9DsJsGfMPc3LczX6n07dRweCibRT7+aOGUNuBAi5Qwa63e68DEaHbg+hZkAd0G5gfVLvuKLWcGNUhdGAyHSUCZEXKNeWAVcpeL0JQeEAdPoTR1LA78RUW5PH/VMiEwXrB22T535m3z6YoPyrrWQnDBcXWJ5rIHtJPT58sB3VVHnV2VjNSBH+hS5fFOQ8pABmW+Z5ajpfy2DxdhtTaLt0hXuLpFon7b7/5XJI8ut57yG0E
</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>Administrator</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2019-05-28T12:24:07.704Z"
Recipient="https://192.168.1.136/index.php/apps/user_saml/saml/acs" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2019-05-28T12:19:07.702Z"
NotOnOrAfter="2019-05-28T13:19:07.702Z">
<AudienceRestriction>
<Audience>https://192.168.1.136/index.php/apps/user_saml/saml/metadata</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername">
<AttributeValue>Aleksandar</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Andric</AttributeValue>
</Attribute>
<Attribute Name="sAMAccountName">
<AttributeValue>Administrator</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2019-05-28T12:19:07.675Z"
SessionIndex="_3acf9e24-2f34-47bf-82fb-97f6d11ab652">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
I am using ADFS as Identity provider and nextcloud as Service Provider, and I can't make them work for 2 weeks. When i click on the sso & saml button on nextcloud http://prntscr.com/nuevag this error occurs and after deleting SAMLRequest and RelayState query parameters and deleting cookies login page is shown http://prntscr.com/nuez9s and after signing in 'Account not provisioned' error appears http://prntscr.com/nuf01w. Log files show http://prntscr.com/nuf0qj but in ADFS, URL is set with https:// http://prntscr.com/nuf11w. Do you have any idea how to make this work. Thank you very much!
You need to trace the SAML request. Either ADFS does not know the Issuer of the SAML AuthnRequest or it may not be able to verify the signature of SAML AuthnRequest (if it was digitally signed).
IdP initiated SSO as shown in https://prnt.sc/nuez9s is a totally different flow, where the IdP only sends a SAML response, there is no SAML AuthnRequest.
ADFS event log would actually show (also sometimes in a somewhat cryptic way) why the SAML AuthnRequest could not be handled.

RightNow SSO with ADFS 2.0

We are currently implementing SSO in RightNow for customers in Customer Portal using SAML 2.0 with ADFS 2.0, but the process is returning the error code 17: "SSO_CONTACT_TOKEN_VALIDATE_FAILED"
IdP generates a signed SAML 2.0 assertion using contact info (the customer’s login name as the assertion subject).
ADFS 2.0 submits the follow assertion using HTTP POST binding:
<samlp:Response ID="_f1e96bb3-3585-4d38-b708-33c8c023a3f1"
Version="2.0"
IssueInstant="2015-02-17T12:20:03.666Z"
Destination="https://company.custhelp.com/ci/openlogin/saml/subject/contact.login"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.company.com/adfs/services/trust/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_5cd4e6a7-0d5a-4010-9979-46cf372b8e35"
IssueInstant="2015-02-17T12:20:03.666Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>
<Issuer>http://adfs.company.com/adfs/services/trust/</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_5cd4e6a7-0d5a-4010-9979-46cf372b8e35">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>QlfQBozfBOCdd4aKqfiqQPTftuQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>EEBAxrW+VHXofNuYPBpzlFR7FZ1Ty4UUOXPFGs3PneU9mSPTpoSAh3BaP/xt2smbmdcj0QWoz00pLZa4KLwUdPdJrKMSqeDwYMvKiNVyQoAbbcS8TzOiFmPdWEgVRIsOY5C/TXjq+aKjnKOwGndTCc9eDvgnlsmo622yP2zHdnLXHlvLfWaPX27CabbYWFjz2ubnpE7Cn5eIcwAZ3VA9qEy3vJvvuBcXfHZ180pHtazNPChI4VycLyNBxzJ92sxkEIsrJZ3X7rqfO6C2IlxTeOHFsvPWCqI05i/IGodGE03x+r1AOc+Qx1fkhAC7TnU96XWjdBJa0lkhQaZtmg7TvQ==</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIFjDCCBHSgAwIBAgIQevLn+V2Y03FErSWKT1CvDjANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLDAqBgNVBAMTI1N5bWFudGVjIENsYXNzIDMgRVYgU1NMIFNHQyBDQSAtIEcyMB4XDTE0MTAzMDAwMDAwMFoXDTE1MTEyNDIzNTk1OVowggEAMRMwEQYLKwYBBAGCNzwCAQMTAkNIMR0wGwYDVQQPExRQcml2YXRlIE9yZ2FuaXphdGlvbjEZMBcGA1UEBRMQQ0gtNjYwLTAzMzI5NzItNjELMAkGA1UEBhMCQ0gxDTALBgNVBBEUBDEyMTcxDzANBgNVBAgTBkdlbmV2YTEPMA0GA1UEBxQGTWV5cmluMR0wGwYDVQQJFBQ3LCBydWUgZGUgbGEgQmVyZ2VyZTEXMBUGA1UEChQORmlybWVuaWNoIFMuQS4xHDAaBgNVBAsUE0luZm9ybWF0aW9uIFN5c3RlbXMxGzAZBgNVBAMUEmFkZnMuZmlybWVuaWNoLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIzG9LYQQxLWjyJ8y4i1DZ9ygSvEPM5jV3GE/J683bFijqt09amec/r3t7LtsZMBEcjyI5Z25vGV8jAcJgpD0Vf980iP9igaFEnlmE4LvPpGMc5uPOv2q+GhPa+TScCefB3HfSbk7d6KShdrAjtQyE+xS11gEHELTHVxyGFbK37Py0P31OTSAYcxP30M0569bl5D0YnkiKmyeEzjXG3novMGFU9xNye15xqmRyoZggc6y/M8QI6BAly9IRm2AiU+wqB0uIT+hUSOseFR/+QU10ZEhKGObro2gbk6x3MueF1MXwY4ngfqE/1eYm9hSte4RFFTox80CetZYlUudy9pqT0CAwEAAaOCAYMwggF/MB0GA1UdEQQWMBSCEmFkZnMuZmlybWVuaWNoLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEAQYKKwYBBAGCNwoDAzBmBgNVHSAEXzBdMFsGC2CGSAGG+EUBBxcGMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1UdIwQYMBaAFEZPweCI2n3TeJvIblkvsOT3HZDiMCsGA1UdHwQkMCIwIKAeoByGGmh0dHA6Ly9zdS5zeW1jYi5jb20vc3UuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL3N1LnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3N1LnN5bWNiLmNvbS9zdS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEjH4BlvVtmV5umudidFRNTTznHVKZD59O3rLGAtC9FoBptA5hstYCu2GxRd2GOouWPYPzoKmNmruSmJmHIzmzoalZ27g4cUYh4kMod/91OEkkFs0E7xXWSVQ1BjZXhdBeFbQ5/rjCEcV8i9uiJuBHioA7s16mkDqN6PFqATYFq2hvZbb0/yPfOrKGFGnz5IxgegSEos1sC6GmFqR5yGxnwXVC5/stXJYmflDFrD/jNZ1995SD4EMXto9SlUcoabj/EelA955x6tjxt9FQUdB9rUI5ahQSrQ/iT1vZ3iCRmlc1Wts/kuYhaq8khggRmmbuBCBh43PIPfvxmrRkdX7XQ=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>PHL</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2015-02-17T12:25:03.666Z"
Recipient="https://xerox-firmenich.custhelp.com/ci/openlogin/saml/subject/contact.login"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2015-02-17T12:15:03.666Z"
NotOnOrAfter="2015-02-17T13:15:03.666Z"
>
<AudienceRestriction>
<Audience>https://company.custhelp.com</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2015-02-17T12:20:03.620Z"
SessionIndex="_5cd4e6a7-0d5a-4010-9979-46cf372b8e35"
>
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
Could be the problem in the SAML assertion?
Usually, this error means that your certificate is either not included in the assertion, or the thumbprint that you've added to your service cloud configuration doesn't match the certificate passed in the assertion. Since you have a certificate, I would focus on the thumbprint. Sometimes, people copy and paste the thumbprint into Service Cloud (RightNow) settings and accidentally copy a return carriage \n or invisible character. Service Cloud considers these characters as part of the thumbprint and will cause this error code if that is the case. Based on the certificate in your example above, that value should be:
39:c6:48:3b:4e:e3:dd:53:c1:58:88:11:c9:33:28:2a:d5:6c:7f:17

Where does the ds:Signature element go in a SAML LogoutRequest?

The PingFederate 6.10 server responds with "Signature required", but the LogoutRequest it receives has a Signature element. Is it in the wrong place? How do I get the LogoutRequest to work?
Perhaps also important: The PingFederate server log says "Exception occurred during request processing org.sourceid.saml20.profiles.StatusResponseException: Request was invalid XML". I don't know which of these errors is accurate; the XML is well-formed, so I've been assuming "Signature required" is the error I should be paying attention to.
(Note that I shortened the X509Certificate, SignatureValue, and Modulus elements' text to make the Request and Response more readable)
Request:
<samlp:LogoutRequest Destination="https://pingfederate:9031/idp/SLO.saml2" ID="_63d86130-2d0e-0130-c98a-58b035fb0c5e" IssueInstant="2012-12-20T12:04:31Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:3000/auth/saml/metadata</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<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="#_63d8f1f0-2d0e-0130-c989-58b035fb0c5e">
<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#"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>+7+DaMHOq7Up//Uoizpn5feSIxU=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>aAn0zuawy59ZXOTjx1...VULz7dVRd0g=</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>LS0tLS1CR...BVEUtLS0tLQo=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">jacob</saml:NameID>
</samlp:LogoutRequest>
Response:
<samlp:LogoutResponse Destination="http://localhost:3000/auth/saml/logout" ID="oWIAl1CbSxM-H9HZKm2L6LyTSDm" InResponseTo="_cab603f0-2dce-0130-c995-58b035fb0c5e" IssueInstant="2012-12-21T19:01:47.530Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">x</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#oWIAl1CbSxM-H9HZKm2L6LyTSDm">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>7HxtM74mkE/t3/UoR8ehE6Wa6x0=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>iGfTRlj25EYZnI496I5V...LHVJyUdgG4cF71wRT0Q=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIICFzCCAYC...gYl9535grCDQbs/zVY=</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>jCMC58LLRg6wQLJQ...VNEll3WQdFPc/hezdjk=</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" />
<samlp:StatusMessage>Signature required</samlp:StatusMessage>
</samlp:Status>
</samlp:LogoutResponse>
SAML Assertions and Protocols Specification (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) says in Section 5.4.2 that the URI attribute of the Reference element must be identical with the ID attribute of the Logout Request element.
In your case, the ID of the Logout Request element is _63d86130-2d0e-0130-c98a-58b035fb0c5e, and the URI of the Reference element is _63d8f1f0-2d0e-0130-c989-58b035fb0c5e. Since these two values are different, PingFederate thinks that the Logout Request is not signed.
I am not acquainted with Ping but in General Saml 2.0 Single Logout Profile is described quite well in Oasis Documentation (Page 32).
I am not sure if this is what you need but I hope that It may be helpfull.
Edit 1: On page 20 of this document you have sample LogoutRequest with signing