Suppose SP-init SSO is carried out, HTTP-Redirect Binding is used instead of HTTP-POST Binding and signed AuthnRequest is required. It means to include the SAMLRequest in the URL.
Q1. Do I need to include the signature in the URL or just embed in the SAMLRequest ?
The redirect url is
http://idp.example.com/SSOService.php?SAMLRequest={val1}&Signature={val2}&SigAlg={val3}
with my SAMLRequest (without signature)
<samlp:AuthnRequest ID="" Version="2.0" IssueInstant="2015-05-22T02:47:38Z" Destination="" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"></saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true" />
<samlp:RequestedAuthnContext Comparison="exact" />
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:AuthnRequest>
or
http://idp.example.com/SSOService.php?SAMLRequest={val1}
with my SAMLRequest (embed with signature)
<samlp:AuthnRequest ID="" Version="2.0" IssueInstant="2015-05-22T02:47:38Z" Destination="" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"></saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true" />
<samlp:RequestedAuthnContext Comparison="exact" />
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>v5h...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>M4...</SignatureValue>
</Signature>
</samlp:AuthnRequest>
Q2. Is it correct to do base64 and url encoded to the value of url parameters ?
Q3. X509 Certificate is included in my SP metadata, is it base64-encoded ?
I have a cert.pem file for the certificate, do I need to make it base64-encoded or just include the certificate directly.
-----BEGIN CERTIFICATE-----
MII...
-----END CERTIFICATE-----
SPMetadata.xml
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIFnzCCA4egAwI...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
A1: when using the Redirect binding you put the signature in the URL query parameters
A2: all URL query parameters should be url-encoded, just the SAML Request should be compressed and base64-encoded in addition to that.
A3: use the PEM format since that is base64 encoded already but leave out the start and end delimiters (----BEGIN-- and ----END CERT...)
Related
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.
We need to setup ADFS as a service provider. So, we tried to send saml response to ADFS. We configured stubs for claims provider, RPT and created certs. We try to send saml to adfs/ls/IdpinitiatedSignon.aspx with RelayState.
Here is Saml Response example.
<samlp:Response ID="_6bcc31a5-fcc2-46a6-a84d-0df2cb5bed17" Version="2.0" IssueInstant="2019-03-27T12:37:34.839Z" Destination="https://srv2012-test-dc.testdomain.com/adfs/ls/idpinitiatedsignon.aspx" InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">anthem.cn.com</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="_eeaaab87-0fcc-4ec1-93d3-ed623b27130c" IssueInstant="2019-03-27T12:37:41.843Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>anthem.cn.com</Issuer>
<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="#_eeaaab87-0fcc-4ec1-93d3-ed623b27130c">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>MkByT8QpjpBFszlr74Rx0IZNewk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>AYhBtCEl4CrsgsuWMaLEDP...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MII...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID>VALERA</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" NotBefore="2019-03-27T12:32:34.839Z" NotOnOrAfter="2019-03-27T13:37:34.847Z"/>
</SubjectConfirmation>
</Subject>
<Conditions>
<AudienceRestriction>
<Audience>https://beta3dev.test.com/</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2019-03-27T12:37:41.843Z" SessionIndex="_56b775bf-32a7-4f35-a370-d707a653a5aa">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute Name="FirstName">
<AttributeValue>valera</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</samlp:Response>
It seems to be valid, we checked by online validators, but ADFS throws exception:
Microsoft.IdentityServer.Web.UnsupportedSamlResponseException: MSIS7029: The SAML response has content that is not supported.
So, The question is: What's wrong with saml?
P.S. Actually, we don't know how an idp intiated scenario works. Maybe there is some minimum pack of claims or we can't login because we don't have working stubs. It will be nice to get some more info about this dataflow.
Ok, it's working now.
There is no request in IdP initiated scenario, so we removed all InResponseTo attributes.
AuthnContext changed to PasswordProtectedTransport.
Name Id can be included but there should be no NotBefore attribute.
We're setting up SSO with Active Directory and Keycloak and trying to configure IdP initiated login. The Keycloak initiated login works, but the IdP initiated login does not, though the SAML responses for each of those is nearly identical (the only difference being inResponseTo on <SubjectConfirmationData> - this is present on the Keycloak initiated SAML response, but not on the IdP initiated SAML response). I've tried with Keycloak versions 4.3.0 and 4.4.0. The IdP settings can be seen here. The Keycloak error and SAML responses are copied below.
Anyone have any ideas on this error?
When trying to log in with the IdP initiated flow, Keycloak returns this error:
ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-62)
Uncaught server error: org.keycloak.broker.provider.IdentityBrokerException:
Could not process response from SAML identity provider.
The SAML response that does get parsed (Keycloak initiated request) is:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://localhost:8443/auth/realms/master/broker/saml/endpoint"
ID="_e531b61c-6523-401c-b267-4a0525c80542" InResponseTo="ID_5d20a349-5af1-4bc8-973d-c7186d0685cc"
IssueInstant="2018-09-26T18:15:25.260Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_0afd4f01-b9a0-4819-865c-e96319da773b" IssueInstant="2018-09-26T18:15:25.260Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<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/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_0afd4f01-b9a0-4819-865c-e96319da773b">
<Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>RGUuFFUrcb3z+ncO3nUsg79tnTjPeB4O/87lPVdw1Dw=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>qP+/5mL5Tln8NKu/Rvz0fWjzMQ1W74UtpULH2OCF88hQtJCO0fGEYlI0kaSk7RSCdbDKx8aWvxkIS0Mi+0vMNGtgs5vWvKzzelm6GTbv7PfOByNd6hsyxBttiaowAsF2JreFJYWBXLr1XQTegA5tCmpmBgKlEVLKGyReF/UJj2/afzPmCkt8ACXq7Dx+Af70sHHHm8WNWJ45P0SHy5Yg/CnyhxC3rNh2MgCe3h9JEJNjNCbrchT9jx97Po80f6KABAaejYtTiUdTtzh7ufFDZ78wami5Z5kpE93X3zKj+CCM2wAWqCu0lQLYeP2KGS1ndK4roFU8iEd4rjuQszXXSQ==</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIDBjCCAe6gAwIBAgIQaERD4XNSb6FBU03xlUaYqzANBgkqhkiG9w0BAQsFADA/MT0wOwYDVQQDEzRBREZTIFNpZ25pbmcgLSBncmVlbmhvdXNlLndlc3R1czIuY2xvdWRhcHAuYXp1cmUuY29tMB4XDTE4MDkxNTE2NDc0M1oXDTE5MDkxNTE2NDc0M1owPzE9MDsGA1UEAxM0QURGUyBTaWduaW5nIC0gZ3JlZW5ob3VzZS53ZXN0dXMyLmNsb3VkYXBwLmF6dXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAND/YMN2tASHJkCTQKfPW695H0Z0THDVTs6AL2y7NvxBgvwOQv5J9jr+QgQsNAr4QE0+jGZ7Z8TTySzySNn22LEGwOXiz4eW5clwtumHfghj1eN4rQDh+1AKxz0VYP4YXdjFemPrnfctlfEusn+/t2QzjrYzzMbC65AWAzPcCEe/udUZJ97ryzjnGx86SC9RR93d6C+HspRD2Sf+967FMG745czKI6paqQLzKe4iueRe+NEhFqLJgjfSQTwGRX8/dxL4KwNGtT0TxNQKiL6HhisyhwtLt3vDYTLBt4cmaalPJKJTFxwBBimb8L9og4IBMiDM5BHpOnQd68OlZLMCMi8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAAqxWIayXbZh1TKQgzGK7fIegHV+hjdHenUdXwzesWv3Wg6tUG/AdVTBn7uPNWV/ne7nCOBN//zwsP/iDD2/FhNDBbHHZz2bU70RDoLPB1TpZ0UkQ6WXILQp57kn4sTCpih5mJ8EwTU17cmcWJps2hpATHbgrHzjOWRqPqgqsXi7/yCYyv4MYQn3efY+HfIgAGc7Ez84ai7OEB2RmRNG93EoUAAR0OZfF+vPelAsdb2lkcb7bji5YKP1lK1mdfI4byFoWyFsnTR0x67EpKu8bOAlIhCaI6tRLT5xi5hMwgEjAplpEF0F2x/KBLPHl829/Y3U6Ze8dUik22imQFwwsEA==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">adminuser#example.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="ID_5d20a349-5af1-4bc8-973d-c7186d0685cc"
NotOnOrAfter="2018-09-26T18:20:25.260Z"
Recipient="https://localhost:8443/auth/realms/master/broker/saml/endpoint"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2018-09-26T18:15:25.260Z" NotOnOrAfter="2018-09-26T19:15:25.260Z">
<AudienceRestriction>
<Audience>https://localhost:8443/auth/realms/master</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>adminuser#example.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2018-09-26T18:08:16.444Z"
SessionIndex="_0afd4f01-b9a0-4819-865c-e96319da773b">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
The SAML response that does not get parsed (IdP initiated) is:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://localhost:8443/auth/realms/master/broker/saml/endpoint"
ID="_89868c3e-98a9-426a-8c49-53b128730584" IssueInstant="2018-09-25T21:22:34.653Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_6968f4ad-d97e-4f46-af2f-cbae662702f8" IssueInstant="2018-09-25T21:22:34.653Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://greenhouse.westus2.cloudapp.azure.com/adfs/services/trust</Issuer>
<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/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_6968f4ad-d97e-4f46-af2f-cbae662702f8">
<Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>FyYk5PDcetumqiefCgrNErVTBi52tGJ8kPGMTCByvUA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>wC9OsDUzNQthY2pLD3hJNgwBceSBvKDcR6AiL2IsQ0A4iGY5tSF0p/YVWyDbe9rLIDcLctn8MQI9FuNCCqMU1QamTtvV1nV9SoPTmMdeC2NgeWnW9HAdg8Sv5tn5bD42E6NAG73RE2fUgWI57rm/+tlt8P3ROdLqXmEaVq5b0wfbqan+QroDxrjn/8oQdUx08mf1P24p37fFtlKWBDW3Oh/gN/0p9MYJIMJ0VjM9jWmoZ0GLz+Zf7NykEB8GzXQfiSWDCiTQfA287TilqpdK1Ni40tUBr1ZEDdqlR1o1gdu4P9rkSJqg1KnB4wwHq1F+cDZ9xVSPBhIBG43jO11D3A==</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIDBjCCAe6gAwIBAgIQaERD4XNSb6FBU03xlUaYqzANBgkqhkiG9w0BAQsFADA/MT0wOwYDVQQDEzRBREZTIFNpZ25pbmcgLSBncmVlbmhvdXNlLndlc3R1czIuY2xvdWRhcHAuYXp1cmUuY29tMB4XDTE4MDkxNTE2NDc0M1oXDTE5MDkxNTE2NDc0M1owPzE9MDsGA1UEAxM0QURGUyBTaWduaW5nIC0gZ3JlZW5ob3VzZS53ZXN0dXMyLmNsb3VkYXBwLmF6dXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAND/YMN2tASHJkCTQKfPW695H0Z0THDVTs6AL2y7NvxBgvwOQv5J9jr+QgQsNAr4QE0+jGZ7Z8TTySzySNn22LEGwOXiz4eW5clwtumHfghj1eN4rQDh+1AKxz0VYP4YXdjFemPrnfctlfEusn+/t2QzjrYzzMbC65AWAzPcCEe/udUZJ97ryzjnGx86SC9RR93d6C+HspRD2Sf+967FMG745czKI6paqQLzKe4iueRe+NEhFqLJgjfSQTwGRX8/dxL4KwNGtT0TxNQKiL6HhisyhwtLt3vDYTLBt4cmaalPJKJTFxwBBimb8L9og4IBMiDM5BHpOnQd68OlZLMCMi8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAAqxWIayXbZh1TKQgzGK7fIegHV+hjdHenUdXwzesWv3Wg6tUG/AdVTBn7uPNWV/ne7nCOBN//zwsP/iDD2/FhNDBbHHZz2bU70RDoLPB1TpZ0UkQ6WXILQp57kn4sTCpih5mJ8EwTU17cmcWJps2hpATHbgrHzjOWRqPqgqsXi7/yCYyv4MYQn3efY+HfIgAGc7Ez84ai7OEB2RmRNG93EoUAAR0OZfF+vPelAsdb2lkcb7bji5YKP1lK1mdfI4byFoWyFsnTR0x67EpKu8bOAlIhCaI6tRLT5xi5hMwgEjAplpEF0F2x/KBLPHl829/Y3U6Ze8dUik22imQFwwsEA==</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">adminuser#example.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData NotOnOrAfter="2018-09-25T21:27:34.653Z"
Recipient="https://localhost:8443/auth/realms/master/broker/saml/endpoint"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2018-09-25T21:22:34.653Z" NotOnOrAfter="2018-09-25T22:22:34.653Z">
<AudienceRestriction>
<Audience>https://localhost:8443/auth/realms/master</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>adminuser#example.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2018-09-25T20:20:26.139Z"
SessionIndex="_6968f4ad-d97e-4f46-af2f-cbae662702f8">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
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
I have ADFS server as an IdP. I have separate SP application. These are defined in circle of trust. SSO over SAML protocol is working fine. When I try SP initated log out request I got error on ADFS side :
MSIS7000: The sign in request is not compliant to the WS-Federation language for web browser clients or the SAML 2.0 protocol WebSSO profile.
EDIT More detail message from ADFS Event Trace :
MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
I have reviewed mu log out SAML message and looks correct. Just to mention that same SP is loging out properly with ForgeRocks IdP (ex Sun OpenSSO).
Saml loout request message :
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="b00b3f55-f3e3-4935-9e91-da6bf8b62efd"
Version="2.0"
IssueInstant="2013-08-27T09:45:08Z"
Destination="https://00.00.00.00/adfs/ls/"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
NotOnOrAfter="2013-08-27T09:50:08Z"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">SPEntityId/</saml:Issuer>
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">jsmith#company.com</saml:NameID>
<samlp:SessionIndex>_ea853497-c58a-408a-bc23-c849752d9741</samlp:SessionIndex>
EDIT
Lan suggested to me that signing of the logout request messages is mandatory. He was right. In OASIS specification (http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) section 4.4.3.1. it is described. According with that I am sending now signed messages but I am having the same issue.
Signed message :
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="aed640c0-9455-49ea-9450-4ad7c08d98e7"
Version="2.0"
IssueInstant="2013-08-29T15:22:45Z"
Destination="https://server/adfs/ls/"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
NotOnOrAfter="2013-08-29T03:27:45Z"
>
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">user</saml:NameID>
<samlp:SessionIndex>_677952a2-7fb3-4e7a-b439-326366e677db</samlp:SessionIndex>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">SPIssuer</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#aed640c0-9455-49ea-9450-4ad7c08d98e7">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>53jjPvQ2Ty1Z+VikwrUwW4Erj3k=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>signed value</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>certificate</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
What I am doing wrong ? Should be specified some other endpoint on ADFS ? As I got is should be used same as for sign on requests (that are working perfectly on my side).
Thanks,
Rastko
Finlay I can do SLO :)
Previously I have worked with ForgeRock's IDP and it worked perfectly, but with ADFS did not. It is obvious that Microsoft has restricted rules related with SAML message formatting. Conclusions that I have found :
LogoutRequest message MUST be signed (SAML 2.0 Profiles doc, Sect 4.4.3.1). Thank you Ian for this.
Order of the XML elements and attributes is important. On the bottom of this message is final version of my log out request.
NameId must be in the same format as one received from AuthenticationResponse. It should contains elements expected by ADFS. These links helped me : Name Identifier (Name ID) claim in the SAML subject and SAML LogoutRequest
LogoutRequest signature must me transformed with XmlDsigExcC14NTransform, that should be added after XmlDsigEnvelopedSignatureTransform
Canonization method for signing should be http://www.w3.org/2001/10/xml-exc-c14n#
Issuer, NameID and SessionIndex are mandatory XML elements
Namespaces are mandatory : xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" and xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Final LogoutRequest message that is working :
<samlp:LogoutRequest ID="f8a62847-92f2-4f0c-936a-df9efe0cc42f"
Version="2.0"
IssueInstant="2013-08-29T20:53:50Z"
Destination="https://server/adfs/ls/"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.com/</saml:Issuer>
<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="#f8a62847-92f2-4f0c-936a-df9efe0cc42f">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>W7F1E2U1OAHRXn/ItbnsYZyXw/8=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate></X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Format="http://schemas.xmlsoap.org/claims/UPN"
>user</saml:NameID>
<samlp:SessionIndex>_2537f94b-a150-415e-9a45-3c6fa2b6dd60</samlp:SessionIndex>
IIRC SAML 2.0 SP-Initiated SLO requires the use of Digital Signatures on the LogoutRequest? This ensures that no one spoofs the LogoutRequest and logs a user out of all their existing sessions.
Assuming you are using the POST binding and not Redirect since I can't see the Signature in the XML. With Redirect the Signature info is passed as a query parameter.