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";>[EMAIL PROTECTED]</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 _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
