Using Public Certificate in Service Provider (Dropbox) Causes SAML Validation Error
markmishaev opened this issue · comments
Hi,
I've connected my business dropbox account to Mujina IDP and uploaded public certificate for SAML assertions validation, but for some reason it doesn't work for me.
I'm getting error "SAML Validation ERROR"
Btw, when validating SAML response with SamlTools (https://www.samltool.com/validate_response.php), validation fails because of incompatible ID's format (response and assertion) - looks like using UUID is not good enough.
Could be please provide detailed instructions how do I do that?
Thanks,
Mark.
Without more information I'm afraid I can't help you. Can you provide me the Mujina stack-trace and the SAML authn request? Also you might consider posting the same information on the Dropbox support forum.
Regardless Dropbox, the test is simple:
Take saml response and validate it with the provided default public certificate here:
https://www.samltool.com/validate_response.php
You will see that the validation fails.
Please see my response as an example:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination="https://www.dropbox.com/saml_login"
ID="_efc7d4a8c6bf662916d2ae7cec35d679" InResponseTo="id-c030751e288d45c792e0fadabdbbc7e1"
IssueInstant="2017-05-30T13:50:09.474Z" Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://mock-idp</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/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_efc7d4a8c6bf662916d2ae7cec35d679">
<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#"><ec:InclusiveNamespaces PrefixList="xs" xmlns:ec="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:DigestValue>8X5VVO6UWCIO4pWLSs07PSxib20=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>KL2dF1lgCDBxBM/t0NMChenxHJc3IFBujldA+RFz3CoL9xzpB5Zz71LSKhVeWdxo51KVoRf157BEctT7GDyPDXES87sZYH5KE+3IayL+SBfhLEShjTvWmHDdZ9yPGCwvqJHUb4y032Ex8Ji5ZM5PdtoY1DJ9kAQOJIWVq5ZO9g62DjebVbPAemjB4WAXBNIq3LGnw8pIw1KzpkN1RmPy33SvuabN9qNoCIdJQMpUgPyaH4QalPUxwxVTlP9QEYmMxkAgASipcdgHWXKfyA0TkV/tdI6WzalLU3xzGfEqlMjtkL7Wjyvli4W1m6VKYMEs0Y/S4hgnJUFKB18vKAIQiQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDEzCCAfugAwIBAgIJAKoK/heBjcOYMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNVBAoMFU9yZ2Fu
aXphdGlvbiwgQ049T0lEQzAeFw0xNTExMTExMDEyMTVaFw0yNTExMTAxMDEyMTVaMCAxHjAcBgNV
BAoMFU9yZ2FuaXphdGlvbiwgQ049T0lEQzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANBGwJ/qpTQNiSgUglSE2UzEkUow+wS8r67etxoEhlzJZfgK/k5TfG1wICDqapHAxEVgUM10aBHR
ctNocA5wmlHtxdidhzRZroqHwpKy2BmsKX5Z2oK25RLpsyusB1KroemgA/CjUnI6rIL1xxFn3KyO
Fh1ZBLUQtKNQeMS7HFGgSDAp+sXuTFujz12LFDugX0T0KB5a1+0l8y0PEa0yGa1oi6seONx849ZH
xM0PRvUunWkuTM+foZ0jZpFapXe02yWMqhc/2iYMieE/3GvOguJchJt6R+cut8VBb6ubKUIGK7pm
oq/TB6DVXpvsHqsDJXechxcicu4pdKVDHSec850CAwEAAaNQME4wHQYDVR0OBBYEFK7RqjoodSYV
XGTVEdLf3kJflP/sMB8GA1UdIwQYMBaAFK7RqjoodSYVXGTVEdLf3kJflP/sMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBADNZkxlFXh4F45muCbnQd+WmaXlGvb9tkUyAIxVL8AIu8J18
F420vpnGpoUAE+Hy3evBmp2nkrFAgmr055fAjpHeZFgDZBAPCwYd3TNMDeSyMta3Ka+oS7GRFDeP
kMEm+kH4/rITNKUF1sOvWBTSowk9TudEDyFqgGntcdu/l/zRxvx33y3LMG5USD0x4X4IKjRrRN1B
bcKgi8dq10C3jdqNancTuPoqT3WWzRvVtB/q34B7F74/6JzgEoOCEHufBMp4ZFu54P0yEGtWfTwT
zuoZobrChVVBt4w/XZagrRtUCDNwRpHNbpjxYudbqLqpi1MQpV9oht/BpTHVJG2i0ro=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status>
<saml2:Assertion ID="_09264d355a2db7d6f8fbd0ac8778f3d5" IssueInstant="2017-05-30T13:50:09.491Z"
Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://mock-idp</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">iftachqa@coronetworks.net</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData Address="https://www.dropbox.com/saml_login"
InResponseTo="id-c030751e288d45c792e0fadabdbbc7e1" NotOnOrAfter="2017-05-30T21:50:09.482Z"
Recipient="https://www.dropbox.com/saml_login"/></saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions>
<saml2:AudienceRestriction>
<saml2:Audience>Dropbox</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2017-05-30T13:50:09.485Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
<saml2:AuthenticatingAuthority>http://mock-idp</saml2:AuthenticatingAuthority>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="urn:mace:dir:attribute-def:cn"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">John Doe</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:displayName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">John Doe</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">j.doe@example.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:givenName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">John</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:mail"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">j.doe@example.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:sn"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Doe</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:dir:attribute-def:uid"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">iftachqa@coronetworks.net</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="urn:mace:terena.org:attribute-def:schacHomeOrganization"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">example.com</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>Additional details:
attached response file
Default certificate also attached.
mujina_cert.txt
There seem to be all kinds of spacing/pretty printing in the response you attached. This is not how Mujina usually sends it. Likely that is why it fails validation. Are you sure response3.txt is the original response?
What error does the SP generate and do their logs have any clue where it fails on?
I copied the response from the chrome SAML extension after the real SAML assertions exchange with dropbox.
Different SPs generate different error messages:
- Dropbox gives a generic message - could not validate SAML response
- Google drive is more specific - "This service cannot be accessed because your login credentials have expired. Please log in and try again."
When googling for message of 2., I have found following description:
For security reasons, the SSO login flow must complete within a certain timeframe, or authentication will fail. If the clock on your Identity Provider is incorrect, most or all login attempts will appear to be out of the acceptable timeframe, and authentication will fail with the above error message.
Check the clock on your Identity Provider's server. This error is almost always caused by the Identity Provider's clock being incorrect, which adds incorrect timestamps to the SAML Response.
Re-sync the Identity Provider server clock with a reliable internet time server. When this issue suddenly occurs in a production environment, it is typically because the last time sync failed, causing the server time to become inaccurate. Repeating the time sync (possibly with a more reliable time server) will quickly remedy this issue.
This issue can also occur if you are re-sending SAML from a previous login attempt. Examining your SAML Request and Response (obtained from HTTP header logs captured during a login attempt) can help you debug this further.
Any ideas?
Thanks,
Mark.
So have you done all the things that are mentioned in that text?
Are the date and time in the response indeed off?
Yes, I have.
As to the times - they look ok - at least in my understanding - still investigating.
Is there still something we can help you with?
Can be re-opened when we receive feedback from https://github.com/markmishaev