[xmlsec] Verifing signature of SAML XML artifacts that has an ID attribute in it, but I think I should ignore it

Tue May 22 14:32:58 PDT 2007

Hello everyone,

Given my time crunch, I've temporarily given up trying to get xmlsec
to work with our sparc64 environment (whatever my issue might be) and
I'm now working with it on a 32-bit intel linux box since I know I can
get it to compile properly there.

I was able to get the example verify3 program working as well as
successfully making my own calls to the library using the example
files.

My ultimate goal is to verify a SAML artifact (a signed XML document
used with a single sign-on (SSO)/federated authentication system). The
XML documents I will be need to verify have 'ID="xxx"' attributes in
them. I admit to being ignorant to the basics of XML signatures, which
is the primary reason I'm trying to use xmlsec. I was under the
general assumption that the IDs, at least as they are used here, are
simply unique identifiers used to associate a thread of transactions.
That is, a request and a response would have the same ID to link them
together. A subsequent request and response would have a different ID,
even though it's the same process and same type of data going back and
forth.

Here is an example of an industry-stanadard SAML "resolveresponse"
artifact that I will need to verify the signature on:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
 <soapenv:Body><samlp:ArtifactResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" ID="id-vNr0lmaihgeRLLV7Kan5GeSmKXI-" InResponseTo="id-xBLscvrh4UbFFFsugsJK8N1FcbMcw0" Version="2.0" IssueInstant="2007-04-24T20:07:37Z"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://fed.couort.net/fed/idp</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><samlp:Response ID="id-J0dTWn9qix-7hd1J3QkT0gHCzHQ-" InResponseTo="id-IBCAA3MVjVcsB6yMKLKV2DZvGegRLX-" Version="2.0" IssueInstant="2007-04-24T20:07:36Z"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://fed.couport.net/fed/idp</saml:Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="id-MnmgTQoTKX1-uz1e4IP3cHP-bV0-" IssueInstant="2007-04-24T20:07:36Z"><saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://fed.couport.net/fed/idp</saml:Issuer><dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#id-MnmgTQoTKX1-uz1e4IP3cHP-bV0-"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><xc14n:InclusiveNamespaces xmlns:xc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/></dsig:Transform>
 </dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><dsig:DigestValue>niJCe9IrQCZ5CTTyOMWGzgvLizc=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo>
 <dsig:SignatureValue>TROpijSd8Jz/dWoWI0piw6nX8Dj0ewQJCjO6z7HAOjCJP4duoK7vg88wVcc+QCBmE8y7uoTIgLTr7kkLFP9NmtlGt2iKBUZNRA3qJoCfY2sflkd9omVZusL3tKB5kuWPf9pCa+O7sHJe6m5LUJmX+ZK0pZCh8ZcomKMQmkSZT10=</dsig:SignatureValue></dsig:Signature><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">06810</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2007-04-24T20:22:36Z" Recipient="https://couiad.com:82/assert" InResponseTo="id-IBCAA3MVjVcsB6yMKLKV2DZvGegRLX-"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2007-04-24T19:57:36Z" NotOnOrAfter="2007-04-24T20:22:36Z"><saml:AudienceRestriction><saml:Audience>http://couiad.com</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2007-04-24T20:07:36Z" SessionIndex="id-MPJzG0p5f006gGPQboYaMv9aNgg-" SessionNotOnOrAfter="2007-04-24T20:09:36Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">scott.sca\@couial.com</saml:AttributeValue></saml:Attribute><saml:Attribute Name="agentnum" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">06810</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response></samlp:ArtifactResponse></soapenv:Body>
</soapenv:Envelope>

When I try to verify that SAML artifact, I get (in part) this output:

func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2 library function failed:expr=xpointer(id('id-MnmgTQoTKX1-uz1e4IP3cHP-bV0-'))
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2371:obj=Visa3DHackTransform:subj=xmlSecTransformExecute:error=1:xmlsec library function failed:
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1207:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec library function failed:transform=Visa3DHackTransform
func=xmlSecTransformCtxExecute:file=transforms.c:line=1267:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec library function failed:
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec library function failed:
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec library function failed:
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:
Error: signature verify

I've tried adding the DTD inside of the XML as suggested in the
mailing list archives, but it didn't seem to have any effect. I also
thought I'd try out the "dsigCtx->flags |=
XMLSEC_DSIG_FLAGS_USE_VISA3D_HACK;" flag setting and it changed the
messages I get but it still failed to validate.

Is there a way to tell xmlsec to ignore the ID attribute? I tried
filtering them out before the call to xmlSecDSigCtxVerify which gets
rid of the xpointer error and just leaves me with:

func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid data:data and digest do not match

So, in my state of ignorance, if xmlsec could ignore the ID attribute,
then the existence of the ID attribute will not cause the xpointer
error and the data will match the digest.

Am I mistaken? If not, how would I go about this?

Thank you for your time.

-- 
James
Funny quotes: "There are 10 types of people in the world. 
Those who understand binary, and those who don't." -- Unknown
"A computer once beat me at chess, but it was no match for me at
kick boxing." -- Emo Philips