I have to do RequestSecurityToken request with certificate signature and timestamp with SoapUI to get security token to use it in other requests, but I have problem to implement it correctly.
Here are correct request, with different application, but with same certificate:
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2016-10-24T14:35:54.851Z</u:Created>
<u:Expires>2016-10-24T14:40:54.851Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken u:Id="uuid-e5fff67c-e3ce-4c63-86da-9661adfd6e0c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">...MIIFgTCCBGmgAwIBAgIKOePZb(shortened)...</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>tsLKDNU0lJ5SB1p75WGVjd7LMHc=</DigestValue>
</Reference>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>4QwJS9rCbZb1B3DcR37qnuJgSl4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...gmAXzaf8hhj44/M0Q(shortened)...</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference URI="#uuid-e5fff67c-e3ce-4c63-86da-9661adfd6e0c-2"/>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
In SoapUI, in WSS config I add as keystore my certificate and made outgoing configuration, where are make timestmap and signature. In Signature, I configure it as binary security token, choose my keystore, alias and password. I have experimented with methods, but most closer result to correct one was this:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="TS-6EB3E416E924850AA51477473502423447">
<u:Created>2016-10-26T09:18:22.423Z</u:Created>
<u:Expires>2016-10-26T09:23:22.423Z</u:Expires>
</u:Timestamp>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" u:Id="X509-6EB3E416E924850AA51477473502407442">...CCBGmgAwIBAgIKOeP(shortened)..." 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="#id-6EB3E416E924850AA51477473502408445">
<ds:Transforms>
<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>ylZ7mgRanKsz3pYpbSXtE3FoVcc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...PwHLpHxINEYUGoCM+Tsz9ucg(shortened)...</ds:SignatureValue>
<ds:KeyInfo Id="KI-6EB3E416E924850AA51477473502407443">
<wsse:SecurityTokenReference u:Id="STR-6EB3E416E924850AA51477473502407444">
<wsse:Reference URI="#X509-6EB3E416E924850AA51477473502407442" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
On this request, i have response with error message
An error occurred when verifying security for the message.
One of differences what I see, is that in correct request there are two references with different URI, than in SoapUI request, but I can't figure out, how to simulate correct request in SoapUI. I would be glad to get some recommendation, maybe someone had the similar problem.
from default soapui only signs the soap-body element.
but you can add each other element from the "Parts:" configuration.
add the following (ID, Name, Namespace, Encode) in the Parts table:
First entry to sign timestamp content
leave ID empty
Timestamp
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
Element
Second entry to sign body content
leave ID empty
Body
http://schemas.xmlsoap.org/soap/envelope/
Element
and soapui will sign the timestamp and body element.
remark: the Timestamp needs to be added before the "Signature" in the list of WSS-Entries.
Related
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?
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.
I'm setting up sso trough SAML using ADFS as identity provider and Nextcloud as service provider and I'm getting following errors: http://prntscr.com/nvba8f on nextcloud and http://prntscr.com/nvbb3w and http://prntscr.com/nvbbfp on adfs. This is my adfs claim issuer configuration 1) http://prntscr.com/nvbc8n
2) added rule on Claimes Provider Trusts http://prntscr.com/nvd5hl
Any and every answer is very appreciated
<samlp:Response ID="_dba1e442-d44b-42da-a10b-b16d4daad325"
Version="2.0"
IssueInstant="2019-05-30T08:58:04.396Z"
Destination="https://192.168.1.136/index.php/apps/user_saml/saml/acs"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="ONELOGIN_5375bf1eef470709c2c4f2808e9d04f8c396518b"
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>
<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="#_dba1e442-d44b-42da-a10b-b16d4daad325">
<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>eh+azCJ1VN90c8Oqm5m+ilgUndA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
2MjM+rjCAyqUKOedfJJpUFxJ/0YHV3SuaWl1t/tooXIeVaSoei38DzrbVW7aMBKh8xGD/4bJa2Wkaljb2UvY1RRWUbeFP7GrOjOwYhXzGnOyFKW3hCvy9DRpe+aWwk2iMNmjCJbJY28i5E5v2UjhsjNXZB08/LiapYjoEvA95xp3q0DKf1EPJHFeUnVw1wwHlvrdhgWOUsV/vuf1kAKM2IiRbzOkxH//ChSH0BplrUqN64ed3Qs97XGzuPTOKuDpUxXz8B28lacC6y9YoQzwNnIiCuAPN6Tw4Xk8kJDn/J93TLJXyUNFe9NwJGr3VYTegG16G7lcLxyERFWdtUMrOA==
</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>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" /></samlp:StatusCode>
</samlp:Status>
</samlp:Response>
The NameID needs to be in the format of "X509 Subject Name".
So take the attribute that you are using for NameID and do a Transform rule with an output of NameID and format of "X509 Subject Name".
Your current format is "email".
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
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