Comments (18)
@tngan i think i was able to fix it. The atob() module i was using to decode the base64 string i was receiving wasn't decoding it properly into utf8. Once i switch to use the native node method of using new Buffer(token, 'base64').toString() this error stopped showing up. But now i'm getting that the canonicalization algorithm isn't supported.
Error: canonicalization algorithm 'http://www.w3.org/TR/2001/REC-xml-c14n-20010315' is not supported
From looking at the source i can see this algorithm isn't listed at least. Is there a major difference between that one and the ones that are supported?
Edit: I tried just for the sake of it to add the key for this canonicalization algorithm to the SignedXml.CanonicalizationAlgorithms in signed-xml.js as an ExclusiveCanonicalization. But that gave me the error thtat the signature was invalid.
Seems there is already an issue #68
from xml-crypto.
What is the error message ?
The following is the possible workaround:
var SignedXml = require('xml-crypto').SignedXml;
var sig = new SignedXml();
sig.signatureAlgorithm = signatureAlgorithm; // you may want to specify your signature algorithm
sig.keyInfoProvider = myKeyInfo(certificate); // certificate is the base64 encoded string
sig.loadSignature(signature.toString()); // signature is whole signature part <Signature> ... </Signature>
var res = sig.checkSignature(xml); // xml is the signed xml document
if (!res) {
console.error(sig.validationErrors);
} else {
console.log('success');
}
You can implement your own KeyInfo method:
function myKeyInfo(x509Certificate){
this.getKeyInfo = function(key) {
return '<X509Data><X509Certificate>'+x509Certificate+'</X509Certificate></X509Data>';
};
this.getKey = function(keyInfo) {
// return the public key in pem format
};
}
So make sure you have used same signature algorithm to verify.
from xml-crypto.
Using your method
Error: key info provider could not resolve key info
<KeyInfo>
<X509Data>
<X509Certificate> <!-- key omitted --> </X509Certificate>
</X509Data>
</KeyInfo>
And my code looks like this
var SignedXml = require('xml-crypto').SignedXml;
var dom = require('xmldom').DOMParser;
var select = require('xml-crypto').xpath;
var KeyInfoProvider = require('./KeyInfoProvider');
var sig = new SignedXml();
var doc = new dom().parseFromString(atob(samlToken));
var signature = select(doc, "/*/*[local-name(.)='Signature' and namespace-uri(.)='http://www.w3.org/2000/09/xmldsig#']")[0];
console.log(signature.toString());
sig.keyInfoProvider = new KeyInfoProvider('x509 certificate as base64'); // certificate is the base64 encoded string
sig.loadSignature(signature.toString()); // signature is whole signature part <Signature> ... </Signature>
var res = sig.checkSignature(atob(samlToken)); // xml is the signed xml document
if (!res) {
console.error(sig.validationErrors);
} else {
console.log('success');
}
When i log the signature i get the correct part so at least that isn't the problem. Also when i look through the XML the getKeyInfo method you supplied looks correct.
from xml-crypto.
The code I've used above is from my module express-saml2. Just for your reference. Error: key info provider could not resolve key info
is because of missing public key. See here
function myKeyInfo(x509Certificate){
this.getKeyInfo = function(key) {
return '<X509Data><X509Certificate>'+x509Certificate+'</X509Certificate></X509Data>';
};
this.getKey = function(keyInfo) {
// return the public key in pem format
return getPublicKeyPemFromCertificate(x509Certificate).toString();
};
}
What is the signature algorithm used to sign the document ? When you verify the document, same algorithm should be used. By the way, what is your KeyInfoProvider
?
Just to clarify here, you have to sign the document with private key and verify the signature using the corresponding public key.
from xml-crypto.
My key info provider is this function you pasted, i just put it in a separate file.
The signature element has these elements:
<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"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
So I'm guessing rsa-sha1
from xml-crypto.
So that's not the problem of signature algorithm. Since you have stated not getting the same digest
before, make sure you have used the right key to verify, if yes, maybe that's the problem of your reference. Is it empty ?
<Reference URI="">
You may also refer to #38 #43, those are digest-related issues, and see whether it helps.
from xml-crypto.
After fixing the get key function I'm now getting the original error again. Which like you said is a digest error.
'invalid signature: for uri calculated digest is ---digest---- but the xml to validate supplies digest ---- not the same digest ----'
from xml-crypto.
You may refer to here.
@yaronn @bjrmatos, any idea of it ?
from xml-crypto.
Here's an example XML document (it's a SAML 2.0 message, forgot to mention before). Don't mind the formatting errors, i copied it from a pdf document
<?xml version="1.0" encoding="UTF-8"?>
<Response Destination="https://login.advania.is/islogin.aspx" ID="_1d62ec4e-ef50-4ca0-ad65-805a126a5e99" IssueInstant="2014-01-17T15:15:52.1725761Z" Version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">Þjóðskrá Íslands</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="#_1d62ec4e-ef50-4ca0-ad65-805a126a5e99">
<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>uDmYbiiCr3Btq3x2IGvHiXnGeJj0cRCnc9cHreQsFFc=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>HnFClmDhLmjG/RBeiFiG2XsIB5jhRAAXmAcNKp+uDYnLvwZWYvUAZg3pkOZ9vjy2hpQ8LKY+/ArXrwL+p6whw8yaHnbvIY9R95GrMhGle5QyDQ9RJB7DvUm4l1Vo/taR4NeB5Y/vpUuaelqeFsz5DY7IzfyfBSkSuydXIPCjd769uI5Jkpg5O3AhWZ5oS3YjP5bU2ghvgm4lUTckYll5u1OgKGlS/woksl2WrlUcvAw0CFnsz4nlN7HM5DMJ15VMQ96hvh aGBQiVgf5ZeYXkwFrZjl3P1rVbnp7CQ4pKTsgwj8eE5Canz0ejdeatIpCMdPh1SzbIlIKCmlu2NtrSrg==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIGDDCCBPSgAwIBAgICCbYwDQYJKoZIhvcNAQEFBQAwgZIxCzAJBgNVBAYTAklTMRMwEQYDVQQFEwo1MjEwMDAyNzkwMRYwFAYDVQQKEw1BdWRrZW5uaSBlaGYuMSMwIQYDVQQLExpVdGdlZmFuZGkgYnVuYWRhcnNraWxyaWtqYTEWMBQGA1UECxMNTWlsbGlza2lscmlraTEZMBcGA1UEAxMQVHJhdXN0dXIgYnVuYWR1cjAeFw0xMzA4MTMxMzU2MzFaFw0xNDA4MTMxMzU2MzFaMIHCMQswCQYDVQQGEwJJUzEeMBwGA1UECgwVw55qw7PDsHNrcsOhIMONc2xhbmRzMRgwFgYDVQQLEw9CdW5hZGFyc2tpbHJpa2kxJTAjBgNVBAsMHFVuZGlycml0dW4gZcOwYSBhdcOwa2VubmluZyAxHTAbBgkqhkiG9w0BCQEWDnZlcmtAaXNsYW5kLmlzMRMwEQYDVQQFEwo2NTAzNzYwNjQ5MR4wHAYDVQQDExVJbm5za3JhbmluZyBJc2xhbmQuaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkWzKHkw3ckRb55wX9K92Rj4yNvOIqj9KUYAaO6dmzSRKtZ3APpbsPL+d1f7ObzSyvPZ6hl0H+mgs1l5nsCc4B1E0xR9t7d5AgwF66xYN/zepPfJ95IV3zlmnnj+CPG4quyJs6HEgyxNH79X9v5lq+xe0WtoHgaY2/vTvceOPOkdksDnCFuD/OvjvVyZ0bTB3Ae0kBNbJRQCAWRpuVSp2I3xEfXhhqbuZOsv+WUvaOL1januOWYi9d6IoaC8CO3RPRvRcS9q5q/iDu2HYECiqT1ZHXu+u7ZosF0Tn1lt0u//8E6YC051F+E2XDCtoqiO7QS0sE9Fntxpmbfv0wrlL1AgMBAAGjggI4MIICNDAMBgNVHRMBAf8EAjAAMIIBHAYDVR0gBIIBEzCCAQ8wggELBglggmABAgEBBAEwgf0wgcQGCCsGAQUFBwICMIG3GoG0VGhpcyBjZXJ0aWZpY2F0ZSBpcyBpbnRlbmRlZCBmb3IgZGlnaXRhbCBzaWduYXR1cmVzIGFuZCBhdXRoZW50aWNhdGlvbi4gVGhpcyBjZXJ0aWZpY2F0ZSBmdWxmaWxzIHRoZSByZXF1aXJlbWVudHMgb2Ygbm9ybWFsaXplZCBjZXJ0aWZpY2F0ZSBwb2xpY3kgKE5DUCkgZGVmaW5lZCBpbiBFVFNJIFRTIDEwMiAwNDIuMDQGCCsGAQUFBwIBFihodHRwOi8vY3AuYXVka2VubmkuaXMvdHJhdXN0dXJidW5hZHVyL2NwMHMGCCsGAQUFBwEBBGcwZTAjBggrBgEFBQcwAoYXaHR0cDovL29jc3AuYXVka2VubmkuaXMwPgYHYIJgAgFjBoYzaHR0cDovL2NkcC5hdWRrZW5uaS5pcy9za2lscmlraS90cmF1c3R1cmJ1bmFkdXIucDdiMAsGA1UdDwQEAwIF4DAfBgNVHSMEGDAWgBRv7NsRLAEDaxtgrrb4aNlAAc2OODBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3JsLmF1ZGtlbm5pLmlzL3RyYXVzdHVyYnVuYWR1ci9sYXRlc3QuY3JsMB0GA1UdDgQWBBQPikAxifriUSZrQMrWjxyY2PjEdzANBgkqhkiG9w0BAQUFAAOCAQEABMMaCGABkb40bOrFxZIM+YDeYYGne4npdM4QGupkv2aDP2bOhohGw9rCbaxL9lm8BHGHtmWwerwX/3lrtnt367pMc/TRon+vVgnxo9wycmP2u2PNyXrEI8X297PBJoKlZ/ouDnITVqH/BVvwaPSiYqz78h/kzQRNtFDGLT8O/CqfCRB5qmGNx8I01tcOMq4EHrc/hwHQc1fogtHJ7JaC5NMO1bg853yl2XC3Dww8OmzAHkCFvKx8aBeEyiesXJHpFj292KohHZhOj1yR5eo9bdqdcjTGkWRn0hN+6vZkdMBIqhkNS7kyxGpvyniCe3VJZIhaXHIZrbx1aYGlyoCvxg==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<Assertion ID="_321427d1-3a6c-4d56-9ada-8d90924f6014" IssueInstant="2014-01-17T15:15:52.1725761Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>Þjóðskrá Íslands</Issuer>
<Subject>
<NameID NameQualifier="island.is">Innskráningarþjónusta</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData Address="127.0.0.1" NotOnOrAfter="2014-01-17T15:25:52.1745763Z" Recipient="http://localhost:63841/GetBack.aspx"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-01-17T15:15:52.1745763Z" NotOnOrAfter="2014-01-17T15:25:52.1745763Z">
<AudienceRestriction>
<Audience>login.advania.is</Audience>
</AudienceRest riction>
</Conditions>
<AuthnStatement AuthnInstant="2014-01-17T15:15:52.1725761Z"><SubjectLocality Address="212.30.225.139"/>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute FriendlyName="Kennitala" Name="UserSSN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">1234567890</AttributeValue>
</Attribute>
<Attribute FriendlyName="Nafn" Name="Name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">Jón Jónsson</AttributeValue>
</Attribute>
<Attribute FriendlyName="Auðkenning" Name="Authentication" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">Rafræn skilríki</AttributeValue>
</Attribute>
<Attribute FriendlyName="IPTala" Name="IPAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">127.0.0.1</AttributeValue>
</Attribute>
<Attribute FriendlyName="NotandaStrengur" Name="UserAgent" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0</AttributeValue>
</Attribute>
<Attribute FriendlyName="AuðkenningarNúmer" Name="AuthID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">0807DA8D-3299-4FF4- BEB2-54727A50FFBD</AttributeValue>
</Attribute>
<Attribute FriendlyName="KennitalaMóttakanda" Name="DestinationSSN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xsi:type="xsd:string">5902697199</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</Response>
from xml-crypto.
I threw this all into it's own repository. See https://github.com/Sk1Zy/node-xml-crypt-issue
from xml-crypto.
So is it possible to update the canonicalisation algorithm to latest version in your Identity Provider ?
from xml-crypto.
I don't have access to it as it is an external provider. But it wont hurt to ask.
from xml-crypto.
I ended up solving this by implementing this like a REST method in PHP and calling that from my NodeJS project.
from xml-crypto.
@Sk1zY Good to hear that, would you like to give more detail of your solution, I do think it would help the further development of this repository.
from xml-crypto.
@tngan I thew the PHP code I used into a gist. However you're gona have to filter out the relevant bits as there is some other validation mixed in that was required by the SAML provider.
I used xmlseclibs to do the XML validation so most of the documentation is found there.
from xml-crypto.
sorry for the late response, busy week.. if i understand properly the final and real issue was that 'http://www.w3.org/TR/2001/REC-xml-c14n-20010315' canonicalization is not supported.. i will try to implement it in the next week
@tngan thnks you for your help!
@Sk1zY thnks for your feedback!
from xml-crypto.
Hi,
I am using xml-crypto in node.js to create Digital signature, i got this error "invalid signature: for uri calculated digest is 1lyn8jGYvy7r4WtL5L401yB2rWE= but the xml to validate supplies digest 7Z8sKYj47RNxPcjPxywArQfmEmg=".can any one plz help ?
from xml-crypto.
hi. i am having very similar problems myself with verifying tokens from this same identity provider. can anyone help? #153
from xml-crypto.
Related Issues (20)
- A Proposal for Moving Forward HOT 1
- refactor: deprecate `SignedXml.signingKey` in favor of `SignedXml.publicKey` and `SignedXml.privateKey` HOT 1
- `xpath` dependency "problem" HOT 10
- [ENHANCEMENT]: Signature compliant to http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 HOT 5
- [ENHANCEMENT]: Export `C14nCanonicalization`, `ExclusiveCanonicalization` HOT 1
- [ENHANCEMENT]: Remove files, folders not needed on the release HOT 2
- Add Reference for the KeyInfo node
- [BUG]: keyInfo usage HOT 4
- invalid signature: for uri calculated digest is '*' but the xml to validate supplies digest '*' HOT 9
- Issue with Signature Verification When 'Transforms' Tag is Absent in 'Reference' Element HOT 5
- How to sign a SAML assertion? HOT 1
- Potentially unsafe default impl for `getKeyInfo()` HOT 2
- [BUG?]: duplicate reference in signature HOT 6
- The declared digest does not match the actual calculated digest HOT 3
- Bug/Outdated README: unclear whether signatureAlgorithm required or not HOT 2
- [ENHANCEMENT]: AddObject to SignedXml instance HOT 4
- [ENHANCEMENT]: wssecurity - getCertFromKeyInfo not possible HOT 1
- [ENHANCEMENT]: Improve experience of adding a `Reference` to the `Signature`.
- [ENHANCEMENT]: Making the signature wrap the content that it's signing HOT 4
- digest is invalid because the computed digest differs from the digest in the XML HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xml-crypto.