Digital signature namespace gets transplanted from Signature to its children? - c#

I am trying to deserialize a signed XML, by using the XmlSerializer.Deserialize method. Then I am sending the resulting object to a web service.
But after deserialization, the namespace defined in Signature gets "cut and pasted" onto all of its children (SignedInfo, SignatureValue, KeyInfo).
This obviously doesn't work because the data is now different and the computed signature is no longer valid and so I'm getting an error from the web service.
For signing my XML I am using SignedXml class, and the resulting signature is something like this:
<RootElement>
...
<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="">
<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>...</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</RootElement>
After deserialization, xmlns="http://www.w3.org/2000/09/xmldsig#" no longer appears in Signature but it does end up in SignedInfo, SignatureValue and KeyInfo. For some reason it gets "inherited" by Signature's children?
This happens regardless of the CanonicalizationMethod used, or different Transform Algorithms, and so on. (I've even tried using SHA-1 etc.) After digging about everywhere, I don't see a way to make it not happen.
I would like to either:
prevent Signature from having a namespace defined at all (it is not required by the web service), or if not,
prevent the namespaces from traveling from Signature onto its children.
In any case, I need the deserialized XML to match the signed original.
Thanks for any help!

Related

How to obtain information from xml digital signature (.cer file) in C#?

I am using service that returns the XML signature. now my task is to identify the signer name from response xml signature.
XML response signature format :
<?xml version="1.0" encoding="UTF-8"?>
<EsignResp errCode="NA" errMsg="NA" resCode="XXXXXXXXXXXXXXXXXXXXXXXX" status="1" ts="2019-05-02T15:15:13" txn="XXXXXXXXXXXXXXXXXXXXXXXX">
<UserX509Certificate>XXXXXXXXXXXXXXXXXXXXXXXX</UserX509Certificate>
<Signatures>
<DocSignature error="" id="1" sigHashAlgorithm="SHA256">XXXXXXXXXXXXXXXXXXXXXXXX</DocSignature>
</Signatures>
<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/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>XXXXXXXXXXXXXXXXXXXXXXXX</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>XXXXXXXXXXXXXXXXXXXXXXXX</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>XXXXXXXXXXXXXXXXXXXXXXXX</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
<X509Data>
<X509SubjectName>XXXXXXXXXXXXXXXXXXXXXXXX</X509SubjectName>
<X509Certificate>XXXXXXXXXXXXXXXXXXXXXXXX</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</EsignResp>
In <UserX509Certificate> tag I get certificate details like Issued to,Issued By, Valid From.
Is there any way to get these information using itextsharp(C#).
You don't need itestsharp for handling and parsing certificates. It's all about pdf and not required for xml.
You may convert Base64 string in to X509Certificate2 type using below code.
byte[] bytes = Convert.FromBase64String("MII<...>==");
var cert = new X509Certificate2(bytes);
Then cert variable above will have properties like
cert.Issuer or cert.IssuerName
cert.Subject or cert.SubjectName
The content may be parsed by split(',').split('=') as per your requirement.

IRS-A2A "message was not formatted properly" (TPE1105 - uniqueTransmissionID)

I am working on integrating the A2A channel for the IRS through their WSDL using WCF. I'm able to get passed any code related errors sending the request but currently receiving the following error back from the IRS:
<faultstring>The message was not formatted properly and/or cannot be interpreted. Please review the XML standards outlined in Section 3 of Publication 5258 (...), correct any issues, and try again.</faultstring>
<detail>
<errorcode>TPE1105</errorcode>
<uniqueTransmissionID/>
</detail>
I'm assuming based on the additional node of <uniqueTransmissionID/> in the response it has something to do with the UTID. I've looked over the format of the UTID and the Soap Envelope examples countless times and can't for the life of me figure out what may be out of place. I tried a small suggestion by fatherOfWine in a previous answer of moving the BusinessHeader up above the Manifest but it returns the same error.
I've added the full request with the Soap Envelope, whitespace appears to be stripped during the request but I've re-formatted it coming from Fiddler.
POST [AATS URL] HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";start="<rootpart>";start-info="text/xml";boundary="--023e657d-66f5-4e92-8e6e-c223338c205a"
SOAPAction: "BulkRequestTransmitter"
Host: la.www4.irs.gov
Content-Length: 15820
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
----023e657d-66f5-4e92-8e6e-c223338c205a
Content-Type: application/xop+xml; type="text/xml"; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Id:<rootpart>
<soapenv:Envelope xmlns:oas1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:us:gov:treasury:irs:ext:aca:air:ty18"
xmlns:urn1="urn:us:gov:treasury:irs:common"
xmlns:urn2="urn:us:gov:treasury:irs:msg:acabusinessheader"
xmlns:urn3="urn:us:gov:treasury:irs:msg:acasecurityheader"
xmlns:urn4="urn:us:gov:treasury:irs:msg:irsacabulkrequesttransmitter">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<Signature Id="SIG-E508633998DD41B6AE062D27D0AC9A48"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#TS-BAC31544F1954B5F8C8441167B91A388">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsse wsa oas1 soapenv urn urn1 urn2 urn3 urn4"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[VALUE]</DigestValue>
</Reference>
<Reference URI="#id-870747663BAB4D6FB43FFAD2034013F1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsa oas1 soapenv urn1 urn2 urn3 urn4"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[VALUE]</DigestValue>
</Reference>
<Reference URI="#id-1A336736A6134B16831D45A0C8785D10">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsa oas1 soapenv urn urn1 urn3 urn4"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[VALUE]</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>[VALUE]</SignatureValue>
<KeyInfo Id="KI-42CB9363E8BE47F2B3E0CD8A743C2D7C">
<wsse:SecurityTokenReference wsu:Id="STR-9EE1B09DD6794A64B00B496CC9DC3804">
<wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">[KEY]</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</KeyInfo>
</Signature>
<wsu:Timestamp wsu:Id="TS-BAC31544F1954B5F8C8441167B91A388">
<wsu:Created>2018-12-27T17:42:39.593Z</wsu:Created>
<wsu:Expires>2018-12-27T17:52:39.593Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
<urn:ACATransmitterManifestReqDtl wsu:Id="id-DB1DDC6A020C433CB71FF38200026E55"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<urn:PaymentYr>2018</urn:PaymentYr>
<urn:PriorYearDataInd>0</urn:PriorYearDataInd>
<urn1:EIN>[EIN]</urn1:EIN>
<urn:TransmissionTypeCd>O</urn:TransmissionTypeCd>
<urn:TestFileCd>T</urn:TestFileCd>
<urn:TransmitterNameGrp>
<urn:BusinessNameLine1Txt>[Name]</urn:BusinessNameLine1Txt>
</urn:TransmitterNameGrp>
<urn:CompanyInformationGrp>
<urn:CompanyNm>[Name]</urn:CompanyNm>
<urn:MailingAddressGrp>
<urn:USAddressGrp>
<urn:AddressLine1Txt>[Address]</urn:AddressLine1Txt>
<urn1:CityNm>[City]</urn1:CityNm>
<urn:USStateCd>[ST]</urn:USStateCd>
<urn1:USZIPCd>[ZIP]</urn1:USZIPCd>
</urn:USAddressGrp>
</urn:MailingAddressGrp>
<urn:ContactNameGrp>
<urn:PersonFirstNm>[FirstName]</urn:PersonFirstNm>
<urn:PersonLastNm>[LastName]</urn:PersonLastNm>
</urn:ContactNameGrp>
<urn:ContactPhoneNum>[PhoneNumber]</urn:ContactPhoneNum>
</urn:CompanyInformationGrp>
<urn:VendorInformationGrp>
<urn:VendorCd>I</urn:VendorCd>
<urn:ContactNameGrp>
<urn:PersonFirstNm>[FirstName]</urn:PersonFirstNm>
<urn:PersonLastNm>[LastName]</urn:PersonLastNm>
</urn:ContactNameGrp>
<urn:ContactPhoneNum>[PhoneNumber]</urn:ContactPhoneNum>
</urn:VendorInformationGrp>
<urn:TotalPayeeRecordCnt>3</urn:TotalPayeeRecordCnt>
<urn:TotalPayerRecordCnt>1</urn:TotalPayerRecordCnt>
<urn:SoftwareId>[SoftwareID]</urn:SoftwareId>
<urn:FormTypeCd>1094/1095C</urn:FormTypeCd>
<urn1:BinaryFormatCd>application/xml</urn1:BinaryFormatCd>
<urn1:ChecksumAugmentationNum>[CheckSum]</urn1:ChecksumAugmentationNum>
<urn1:AttachmentByteSizeNum>[Bytes]</urn1:AttachmentByteSizeNum>
<urn:DocumentSystemFileNm>1094C_Request_[TCC]_20181226T161942345Z.xml</urn:DocumentSystemFileNm>
</urn:ACATransmitterManifestReqDtl>
<urn2:ACABusinessHeader wsu:Id="id-E71242CFDF04487D9ECA0AC2E1544E90"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<urn:UniqueTransmissionId>6de74234-d0fd-45b2-ad45-b408fd137201:SYS12:[TCC]::T</urn:UniqueTransmissionId>
<urn1:Timestamp>2018-12-26T16:19:42Z</urn1:Timestamp>
</urn2:ACABusinessHeader>
<urn3:ACASecurityHeader>
<urn2:UserId>1#######</urn2:UserId>
</urn3:ACASecurityHeader>
<wsa:Action>BulkRequestTransmitter</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<urn4:ACABulkRequestTransmitter version="1.0">
<urn1:BulkExchangeFile>
<inc:Include href="cid:1094C_Request_[TCC]_20181226T161942345Z.xml"
xmlns:inc="http://www.w3.org/2004/08/xop/include" />
</urn1:BulkExchangeFile>
</urn4:ACABulkRequestTransmitter>
</soapenv:Body>
</soapenv:Envelope>
----023e657d-66f5-4e92-8e6e-c223338c205a
Content-Type: application/xml
Content-Transfer-Encoding: 7bit
Content-Id: <1094C_Request_[TCC]_20181226T161942345Z.xml>
Content-Disposition: attachment; filename="1094C_Request_[TCC]_20181226T161942345Z.xml"
<?xml version="1.0" encoding="utf-8"?>
<n1:Form109495CTransmittalUpstream xmlns="urn:us:gov:treasury:irs:ext:aca:air:ty18"
xmlns:irs="urn:us:gov:treasury:irs:common"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xsi:schemaLocation="urn:us:gov:treasury:irs:msg:form1094-1095Ctransmitterupstreammessage IRS-Form1094-1095CTransmitterUpstreamMessage.xsd"
xmlns:n1="urn:us:gov:treasury:irs:msg:form1094-1095Ctransmitterupstreammessage">
[Removed for Space]
</n1:Form109495CTransmittalUpstream>
----023e657d-66f5-4e92-8e6e-c223338c205a--
Update: I added the Security Header and have gotten passed this specific problem, now working on resolving the WS-Security error. I've also updated my envelope with what has changed.
Just throwing this out in the wind (more of a comment but too long), but it looks like you are missing these to elements from their example:
<urn4:ACASecurityHeader xmlns:urn4="urn:us:gov:treasury:irs:msg:acasecurityheader" />
<oas:Security xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-secext-1.0.xsd" />
You are using this prefix for urn3, which is not referenced in any elements from what I can tell. Not sure if it makes any difference or not, but the above to elements do precede the section that is giving you an error. Feel free to disregard if it sounds like non-sense to you.
I'd like to add to this, one of the things that I learned through developing this process a couple of years ago: the request you send, whether for status or submission, needs to be identical to their example.
The method I used to accomplish this was to create separate XML template documents (one for Submission one for Status) which contains the entire XML needed for each request.
At a high-level, my application uses the WSDL objects by populating them with appropriate data, then I replace the XML elements in the template with values from the objects, sign the XML document, attach the form data (for submission), and send the request.
Reviewing what you posted and comparing it to what I have previously transmitted, I found a couple of differences:
In your envelope definition, you have an attribute xmlns:oasl, I do not have this.
In your InclusiveNamespaces element, I have PrefixList="wsse wsa soapenv urn urn1 urn2 urn3". I was told having this literal value was a must.
Your DigestMethod is sha256, while mine is sha1. I understand there is a difference between the two, but this could be causing you some problems?
I have a urn3:ACASecurityHeader element containing a urn1:UserId element, which I think you have already resolved (its just not updated in your original post)
Here is the envelope I am currently attempting to send which is resulting in a TPE1122 WS Security Header error being returned.
The following envelope XML is a working envelope for transmission for TY2018. Information has been redacted.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:us:gov:treasury:irs:ext:aca:air:ty18"
xmlns:urn1="urn:us:gov:treasury:irs:common"
xmlns:urn2="urn:us:gov:treasury:irs:msg:acabusinessheader"
xmlns:urn3="urn:us:gov:treasury:irs:msg:acasecurityheader"
xmlns:urn4="urn:us:gov:treasury:irs:msg:irsacabulkrequesttransmitter">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<Signature Id="SIG-E9efb6eb0a76b4277a5cf8dc3930a868d" xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#TS-E057d0d55370e45a8bc8a42f995a89aa3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsse wsa soapenv urn urn1 urn2 urn3"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[TIMESTAMP DIGEST VALUE]</DigestValue>
</Reference>
<Reference URI="#id-Ed6c3f891454e4eeaa73aeacaf21b6857">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsa soapenv urn1 urn2 urn3"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[ACA BUSINESS HEADER DIGEST VALUE]</DigestValue>
</Reference>
<Reference URI="#id-Eda32be00e9954326a8dbbd30a86a975e">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsa soapenv urn urn1 urn3"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>[ACA TRANSMITTER MANIFEST DIGEST VALUE]</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>[SIGNATURE VALUE]</SignatureValue>
<KeyInfo Id="KI-E70e6fef54fa44300bf8f732831579e03">
<wsse:SecurityTokenReference wsu:Id="STR-Ee23913563c7843c7917a3c63f9830d6f">
<wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">[CERTIFICATE KEY IDENTIFIER]</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</KeyInfo>
</Signature>
<wsu:Timestamp wsu:Id="TS-E057d0d55370e45a8bc8a42f995a89aa3">
<wsu:Created>2019-01-07T16:32:54.353Z</wsu:Created>
<wsu:Expires>2019-01-07T16:42:54.353Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
<urn:ACATransmitterManifestReqDtl wsu:Id="id-Eda32be00e9954326a8dbbd30a86a975e"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
[MANIFEST DATA]
</urn:ACATransmitterManifestReqDtl>
<urn2:ACABusinessHeader wsu:Id="id-Ed6c3f891454e4eeaa73aeacaf21b6857"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<urn:UniqueTransmissionId>e8d5fbcf-564d-4e31-8b48-ecc2fffe8fc0:SYS12:[TCC]::T</urn:UniqueTransmissionId>
<urn1:Timestamp>2019-01-07T08:32:54Z</urn1:Timestamp>
</urn2:ACABusinessHeader>
<urn3:ACASecurityHeader>
<urn1:UserId>[USER ID]</urn1:UserId>
</urn3:ACASecurityHeader>
<wsa:Action>BulkRequestTransmitterService</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<urn4:ACABulkRequestTransmitter version="1.0">
<urn1:BulkExchangeFile>
<xop:Include href="cid:1094C_Request_[TCC]_20190107T163254215Z.xml" xmlns:xop="http://www.w3.org/2004/08/xop/include" />
</urn1:BulkExchangeFile>
</urn4:ACABulkRequestTransmitter>
</soapenv:Body>
</soapenv:Envelope>

How can I sign a xml file with an x509 certificate in .NET Core?

I am struggling with signing an XML document to be sent as a SAML 2.0 Request. I need to do this in Asp.Net Core.
The library that would help me with this problem System.Security.Cryptography.Xml is not available in .NET Core. I was thinking if there is a manual way to sign a xml document with specified signature algorithms and canonicalization method.
The initial xml document is:
<saml2p:AuthnRequest ID="_6cf0de52-7baa-42a6-bde9-1b3758876e23" Version="2.0" IssueInstant="2017-08-08T12:36:52.5360695Z" Destination="*hidden*" AssertionConsumerServiceURL="*hidden*"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>*hidden*</saml2:Issuer>
<saml2p:NameIDPolicy AllowCreate="true"/>
</saml2p:AuthnRequest>
And I need to obtain:
<saml2p:AuthnRequest ID="_6cf0de52-7baa-42a6-bde9-1b3758876e23" Version="2.0" IssueInstant="2017-08-08T12:36:52.5360695Z" Destination="*hidden*" AssertionConsumerServiceURL="*hidden*"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>*hidden*</saml2: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="#_6cf0de52-7baa-42a6-bde9-1b3758876e23">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>ECaUeAOFJKloXmSPfKqB67S8QWU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>Rpj8w+29giFaKvnWO9Fjz4cs12mm+VcchYK3Y7T2iT7y48TejOYzKhBHIQ5JUZ/dRZ+B7Rc+PeAmixyR43WYyLpOoHGHL7kBj/Ols5eO5OXNAlcTocv1PUhAxn0onJeuX7vzWewmuRf9t8fItXrZFopFSaGHkDk0gYuRCEBf15seukaf9XT9EwRKt/bz8a5LaCqDH+sWEt8OUZucpUOlrMTaP9zx1/0+M6V3YM5DvndPuZcSKlyStELp1okXnxeMENwGBGB1XJwSP+VwbWADz6J0SB9sqNzMNF7YOAvZCdkYhxalIJ5VQll3dg+ZT5g/vGmKHehNhPDsjsnK+5W2OQ==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDETCCAf2gAwIBAgIQ8VcaEM0KNqNKVdi240uVlTAJBgUrDgMCHQUAMB4xHDAaBgNVBAMTE3NhbXBsZS5tcGFzcy5nb3YubWQwHhcNMTQwNzE2MTExMjI4WhcNMzkxMjMxMjM1OTU5WjAeMRwwGgYDVQQDExNzYW1wbGUubXBhc3MuZ292Lm1kMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjJB1ZunoQVBBcIDUGDnDogjSzzYOZ+jaLFHGHIABA05IbPqLl6xJqKOT9ykC/jIYHbNkNiBF6FSrpU3qWfALJ7rZHef4IksQHEz0vqXq4LMVDBBVBCon4YtE9uZWmZU+m2us63MI0RQrj4mg4+u2RvQqEbDTPG5u5mmbcrLcl/tnN2wsOnLvCNFT9j2RLMKgEB9jKubRszKG1dEVkphgxm5S7lqmOXQWX24n9rBHro2fuuA5DE7GIF6YU9B3oCIFB5jRJcoWL3rX30cUb0sxlJXmVKEt1pOqt8n5aheWPFPtnBtIH13hLxVTqmWW7JUk+SgMdPLGpqxmtv6sPWOI2QIDAQABo1MwUTBPBgNVHQEESDBGgBC5sKpnobhhHkO5u+Vp8jpXoSAwHjEcMBoGA1UEAxMTc2FtcGxlLm1wYXNzLmdvdi5tZIIQ8VcaEM0KNqNKVdi240uVlTAJBgUrDgMCHQUAA4IBAQASmfVnZjEGPlmWK3X+vMZdSUw/FU11NdHIjwO8YA6OqNYHrHPOwLlgUlycr/VYs73s0wI1b+SaC2/lsbkXAF1w83jy3FHnipFjEkV1+d0ogmox4WFX0PVyeAwVO99swzU1ERrEoXQ/kIgtGe7FYrZ+3H+x0nae9fKnGOlW0GctwoZmG0zk2reU0AuQHj9GAkHK5nF7KAQg1VEdI/WsMxaz+ZS/ZS1882GEl6ZNKrhRIGrO4tGRFI9yYHEW2qzjewKIUrAba/ifdPsk37nJwJvlAD+gSUUeENCzHbZvx8iiNmxcGr1/6gB6Dub+Qc8NvrvVcWvPq+0Gox1rSQi/yQT0</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml2p:NameIDPolicy AllowCreate="true" />
</saml2p:AuthnRequest>
Thank you in advance.
The SignedXml class is available in .NET Core 2.0 Preview 2, though you will need to explicitly reference the System.Security.Cryptography.Xml package, since it's not part of .NET Standard.
If you can't move to .NET Core 2.0 (which should be releasing any time in the next couple of weeks) then you'd have to find a 3rd party library or write it yourself. Given how complex the xmldsig and c14n specifications are, I'd strongly recommend against writing it yourself.

trying to implement SSO for dynamics 2011 w/ ADFS 2.0 claims- claims not being passed through

I'm trying to implement an SSO for microsoft dynamics 2011 as described in this (very poorly written) walkthrough.
I've configured my ASP.NET website as a relying party in ADFS manager, and followed the instructions to add an STS reference.
I've defined an issuance transform rule for the UPN field in ADFS.
In my ASP.NET application, when doing this-
IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)(Thread.CurrentPrincipal)).Identities[0]; I do get an instance of Microsoft.IdentityModel.Claims.ClaimsIdentity, however, its Claims collection is empty.
I've noticed, however, that the FederationMetadata.xml generated by the 'add sts' wizard only contains 2 <auth:ClaimType> elements- for name and role, both optional=true.
However, if I try to manually edit and update my relying party's FederationMetadata.xml to add upn as a claim type, or to make one of the existing claim types non-optional, I encounter the following error- ID6018 Digest verification failed....
If I revert back to 'optional=true' for both, the error doesn't occur.
Can anyone provide any insight as to how to get the UPN field to my ASP.NET app?
Also, better how-to's / walkthroughs than the one I've mentioned would be greatly appreciated.
I'm not really sure what further information to supply here, so i'll just post my application's FederationMetadata.xml:
<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor ID="_bad84517-5281-47e8-be9d-2e1a78eae772" entityID="https://MyAspnetSite.com:4455/"
xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<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="#_bad84517-5281-47e8-be9d-2e1a78eae772">
<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/2001/04/xmlenc#sha256" />
<ds:DigestValue>
eWoZYLA/oMNMWd+S9m0TlbIg2rUSuumAckA0BTdAqbg=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
yMubsY42ZblFDP4ZFEO06uT317c/xdMUF7PrOhPpShkDtbigg1TWq3tGYEa35+xpfjqQCseHJH07ftkxOH6t0u6ngqbGCmZ4yaOBTA3bdbGMGull6WwLSQIxNn2eR1mRzyF2mIM3t4Jfl6EoOZ0msnsyUTVI9Oq03eFweDN2zoI=
</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
certificate data
</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<RoleDescriptor xsi:type="fed:ApplicationServiceType"
protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
certificate data
</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<fed:ClaimTypesRequested>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="false"
xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="false"
xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.microsoft.com/ws/2005/05/identity/claims/upn" Optional="false"
xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
</fed:ClaimTypesRequested>
<fed:TargetScopes>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>
https://MyAspnetSite.com:4455/
</Address>
</EndpointReference>
</fed:TargetScopes>
<fed:ApplicationServiceEndpoint>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>
https://MyAspnetSite.com:4455/
</Address>
</EndpointReference>
</fed:ApplicationServiceEndpoint>
</RoleDescriptor>
</EntityDescriptor>
You can't modify the FederationMetadata document directly because it is digitally signed. If you do, it will be rejected by ADFS, as it believes it has been tampered with.
Anyway, the metadata doc doesn't control what claims are being issued in ADFS. In addition to adding the RP, you need to create rules in ADFS that define what claims will be issued for this RP.
This other doc for CRM explains how to do it.
Well, for the benefit of the poor souls that may encounter this in the future, I'll document what the problem was for me:
The 'Add STS reference' wizard has altered my web.config in a wrong way.
I don't know why that is, perhaps it's because I had a pre-existing <system.serviceModel> section, but the wizard added the <claimTypeRequirements> section and all sorts of other stuff under <system.serviceModel> \ <bindings> \ <ws2007FederationHttpBinding> which didn't really seem to do anything.
I ended up deleting it and manually adding the appropriate <microsoft.identityModel>
section.
That seemed to have done the trick.

Which bits of SOAP / WS-Security / WS-Addressing / etc do I need to send this message

EDIT:
I think the only bit left to understand is the signing of the message using the username token profile. Any pointers/clues/info on how to implement that would be great. I have played with the Visual Studio .Net 2003 with WSE 2 and the username token profile sample does this be default- so my fallback is to use that, but prefer to run on Linux, as that is the server we have. Plus no Mono port of WSE. I get the impression that this is not used much/its deprecated...
I have to talk to a Web Service and have been given the sample below. I am trying to translate this into English... or at least understand which bits of the WS security specs I need to be looking at to communicate to it.
I am using Ruby/Savon for other WS calls, but it seems to only support basic WSSE, username/passwords.
I can see this message has a Signature - but is it signed via an external file/certificate/code or do I have enough details below to do the same signing within my own code.
I dont see any X509 or Cipher entries which seems to imply its not done with such a certificate (in my naive understanding of this), so what is being used to produce the Signature- perhaps just a simple hash of the message?
It also seems to use some sort of digest/message checking as when I try tweaking the sample and resending it, its bounced as invalid - although I guess this might be related to the signature issue...
I dont think Savon supports this and so I am thinking I need to switch to JRuby and use a Java WS library, perhaps Rampart with Axis2 or maybe Spring security bits. Any tips/reccomendation/good tutorials? I see this from IBM, but thinking I need something higher level so I can grasp the "big picture"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soap:Header>
<wsa:Action wsu:Id="Id-6762c167-412b-4bf8-8839-518e9bc25da5">
http://host/path/func</wsa:Action>
<wsa:MessageID wsu:Id="Id-00bb0af8-232d-43a8-adbb-39f230599c56">
uuid:2005639d-39b8-4df6-bf41-e18741c45291</wsa:MessageID>
<wsa:ReplyTo wsu:Id="Id-c53a1dbe-244f-46a9-b656-883f4b06dcfe">
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To wsu:Id="Id-017877f6-e5a3-43ae-aa2b-4886adb7060c">
http://host/path/func.asmx</wsa:To>
<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="Timestamp-1a38d0f9-077f-4e95-991b-fa899a171920">
<wsu:Created>2011-03-14T15:00:09Z</wsu:Created>
<wsu:Expires>2011-03-14T15:05:09Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-42ae32d2-f6ff-431e-9369-7696b44965e3">
<wsse:Username>crypteduser</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
cryptedpass</wsse:Password>
<wsse:Nonce>fLSoqLm9kuOumxy39JRHaw==</wsse:Nonce>
<wsu:Created>2011-03-14T15:00:09Z</wsu:Created>
</wsse:UsernameToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
<Reference URI="#Id-6762c167-412b-4bf8-8839-518e9bc25da5">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>SAYl5o1kh33HteOe0L7G6KIKqWg=</DigestValue>
</Reference>
<Reference URI="#Id-00bb0af8-232d-43a8-adbb-39f230599c56">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>//LMuFkNC1FO1/9A9W7l6o75Y2M=</DigestValue>
</Reference>
<Reference URI="#Id-c53a1dbe-244f-46a9-b656-883f4b06dcfe">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>9pgN7bU48UKi1UTnpOCikOnp2G0=</DigestValue>
</Reference>
<Reference URI="#Id-017877f6-e5a3-43ae-aa2b-4886adb7060c">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>lWZNjtSHfVtiZeOFZAosV868Uos=</DigestValue>
</Reference>
<Reference URI="#Timestamp-1a38d0f9-077f-4e95-991b-fa899a171920">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>H3nYPY6kfIWEIWQhpwaz8VKeQIM=</DigestValue>
</Reference>
<Reference URI="#Id-f95dfea2-3af8-4e95-8e60-141858db9532">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>uRTu+Hzxw+zdaTYgW0z+j35diIQ=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
Hdn2wxWhmr450pefMuc41o6GgOA=</SignatureValue>
<KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#SecurityToken-42ae32d2-f6ff-431e-9369-7696b44965e3"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" />
</wsse:SecurityTokenReference>
</KeyInfo>
</Signature>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="Id-f95dfea2-3af8-4e95-8e60-141858db9532">
<func xmlns="http://host/path/">
<xml_in>yucky xml inside xml...</xml_in>
</func>
</soap:Body>
</soap:Envelope>
Many thanks in advance for any tips/pointers you can give.
Regards,
Chris
EDIT
Seems similar to this question... which does use an X509 cert, so perhaps it is needed.
Currently reading the wikipedia entry for this.
EDIT2
Seems like its this - hopefully the username based option... http://msdn.microsoft.com/en-us/library/ms824647.aspx
EDIT3
I think I have most of it sorted now - the main thing outstanding is the username digest'ing. How do I do it - where does the signature value come from...
EDIT4
Thinking my best bet is to write a client in .Net and either that will give me enough clues to do it directly in Ruby, or I can wrap it in a simpler version - at least for the short term...
This isn't really a full answer, but just a few things I've noticed.
The wsse:SecurityTokenReference refers to this document (in the cryptic sort of soap way): http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
I would read through: 3.2 Token Reference
Also, the parent section mentions this formula:
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
Maybe try something like this for the signature?
Password_Digest = Base64 ( SHA-1 ( nonce + created + UsernameToken ) )

Categories