everyone. I have a mystery. It may be obvious to someone, hence this.
About 10 days ago, my Service Provider app started to throw a curious error after working flawlessly for several weeks. I have a service provider running both locally and on Azure. The app uses KentorAuthServices to handle the messy XML and crypto bits. It was running smoothly and then, suddenly, it began to throw the error, "Could not create hash algorithm object." I enabled framework debugging and traced it to the very location indicated in the last line of this extract of the stack trace:
[CryptographicException: Could not create hash algorithm object.]
System.Security.Cryptography.Xml.Reference.CalculateHashValue(XmlDocument document, CanonicalXmlNodeList refList) +160912
System.Security.Cryptography.Xml.SignedXml.CheckDigestedReferences() +154
System.Security.Cryptography.Xml.SignedXml.CheckSignature(AsymmetricAlgorithm key) +73
Indeed, it cannot create the hash algorithm object because the algorithm represented by this URI
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
now purports to be unsupported, despite having a custom handler for it built into KentoAuthServices-and which worked as expected until this sudden turn of events. Just as a sanity check, I pointed the SP app at Kentor's own stub IdP and the app behaves as expected. As well, I validated the SAML response, which I will reproduce below, against OneLogin's SAML validation utility, which also reports that the response is valid but that the algorithm is unsupported.
Things I do know:
The Azure AD cert is current, complete, and accessible in the Trusted
Root cert store of LocalMachine, and created after the October 10
policy change for rollovers (which should be irrelevant here anyway).
The SP is not signing the request with any kind of funky, self-signed
cert; nor did it ever.
Both locally and on Azure, the app is pegged to
an SSL port.
The configuration of the app--EntityId, Issuer, metadata
location and loading, binding, request signing behavior; and so
on--has remained unchanged--except for my testing, which added a swappable IdP reference pointed to the stub provider.
Azure AD successfully processes the request and
issues a response, which is otherwise valid; however,
System.Security.Cryptography cannot create the hash for the
signature.
I feel like I'm missing something obvious, except for the fact that the app was unchanged from one day to the next; hence, I'm obliged to ask if anything in the world has changed to explain why rsa-sha256 is coming up dead. Here's the redacted SAML request and response for your perusal. Most identifying info is removed, but you already know it's from Azure AD so the cert is present and you can validate it for your edification. Thanks, and have a great day.
<saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="id1cf99748a239485692824ff1b950b5f9"
Version="2.0"
IssueInstant="2016-11-29T16:44:34Z"
Destination="https://login.windows.net:443/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2"
AssertionConsumerServiceURL="https://xxxx.azurewebsites.net/AuthServices/Acs">
<saml2:Issuer>https://xxxxx.xxx/federation</saml2:Issuer>
</saml2p:AuthnRequest>
<samlp:Response
ID="_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Version="2.0"
IssueInstant="2016-11-29T16:44:36.521Z"
Destination="https://xxxxxxxx.azurewebsites.net/AuthServices/Acs"
InResponseTo="id1cf99748a239485692824ff1b950b5f9"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/
</Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion
ID="_xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx"
IssueInstant="2016-11-29T16:44:36.505Z"
Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/</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="#_2a5aa895-bcf1-4f98-87d6-187e7d75338c">
<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/xmldsig-more#rsa-sha256"/>
<ds:DigestValue>
HE62WvhO505xxxxxxxxnopQTPfL6LybGYySKUKfBxtY=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>E8bvvT1iw148RaVOtlPWWMhPMq121arxJ2lwRd3Boi5Xe3Lw+sc9TgCWsmFa4tcIq0idmYTkYVio4cBDNnzIcMqy28JeeiF53nriO3eyxRQiPeJhyy6JUFnbhWEa6DcYvIbD14izrvdQGuGzULeL8K2cc32xDnCjYZXAWvY4V+iaEJhXqc50bfplUXwTcgo2YzPckmh/+iad0jVFBBj1S7bMDp9+hOvUHgrwU/FIm8H7Y/g6rZZ2mlkEsdRP0WRQfCgI/IHLf1IqUdaGE9hZpqcecmtAiKytWIe/0z/8zzUC3Xp2f+L2XEXMH3Y7iNOyKr38X3FQ/
OChWEdYLIj3rw==
</ds:SignatureValue>
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIC8DCCAdigAwIBAgIQNJKIhylW6qVJDAuPDpyGfDANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0xNjExMjQxNDI2NTlaFw0xNzExMjQxNDI2NTlaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQgU1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApMAryO4ZkQ5WE+2QOK1oe8cXa00JH4zGDjRF92Nj4s8NrPF+2zR2IwTYV3yH5kTckCYU2+i+jDr4lBRvjG+LSoN9xdUtu4pF9Ya1v6VN6ELWnTtZYSMY7Xh3ztjF7jmWFSEvANTcTLq5wSfbZuDfti6zdJ+TP6DSN6Q3cR0wqdPJbR4NlQdpmIVAIHrpur218IhRSMcodxlKdS47cU7jTb1Vqo9uzRmrz9l5aZnPgxzv2OKHafD7E/eDIUMjkfOoZbNJJIfBy1wrGUHBLdb318VVIMDtym4Xw52TuFJ1O0dWRZU4pGGh8Vo81Hz689i8cTYv0v4bUmUeCE9kHOTHbQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAuoJMRWb3hj0f7Bg8jFTRizA+3sVXI98MKRCmxDHy84LQi5VE8VOW9TXXN8cfPQ0MlFOGg5aeePWMjr4Pmwfq5Q1aZ0JsQszAIhKzIq1jGadwlkAs1VKA37oHa6aa8OrAtLYhA5xwqq5q6oE1AULuC7g697FoSO0Q8MpHl6VCxvuqXzHQ/KYXiJ6hqpHTZN8eliBwio7+xP0O23QdM0sgkO5EvdSiuB5s23e77iutJD8YvD+oOz3QVf9OeOuocK1TtQmFaiI3kkliM1sfWowHjfIOiPjNpSBmEuKiq02XCWTDzkuYCxcRdgVnhRG+/SRqv+OTJIs6vnAWrtsFIbRGt</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">xxxxxxxxx.xxxxxxxxxxxxxxx#Xxxxxxxxxxx.com
</NameID>
<SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData
InResponseTo="id1cf99748a239485692824ff1b950b5f9"
NotOnOrAfter="2016-11-29T16:49:36.505Z"
Recipient="https://xxxxxxxxxxxxxxxxxxxxxxx.azurewebsites.net/AuthServices/Acs"/>
</SubjectConfirmation>
</Subject>
<Conditions
NotBefore="2016-11-29T16:39:36.505Z"
NotOnOrAfter="2016-11-29T17:39:36.505Z">
<AudienceRestriction>
<Audience>https://xxxxxxxxxxxxxx.com/federation</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute
Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>ccbf68cb-7932-44bd-b015-cb686e0a4441</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>94d0114a-c4b8-4568-bf63-4b597aa65eda</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.microsoft.com/identity/claims/displayname">
<AttributeValue>xxxxxxxxxxxxxxxxxxxx</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>live.com</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>xxxxxxxxxxxxx</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>xxxxxxxxxxxxxxxxxxxxxxx</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>xxxxxxxxxxxxxxxxxxxxx#Xxxxxxxxxxxxxxxxxx.com</AttributeValue>
</Attribute>
<Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>xxxxxxxxxxxxxxxx.xxxxxxxxxxxx#xxxxxxxxxxxxxxxxxxxx.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement
AuthnInstant="2016-11-27T02:37:17.000Z"
SessionIndex="_xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
Related
I would like to get the invoice link from the purchase order implementing Sage Intacct API via Postman.
I suppose it can be done by following sequences(or by only one api request? not sure about this).
Order a purchase
Create a purchase receipt
Get an invoice link from it
Please refer to this API document (https://developer.intacct.com/api).
i.e. This is the body of a request to create a purchase transaction.
<?xml version="1.0" encoding="UTF-8"?>
<request>
<control>
<senderid>{{sender_id}}</senderid>
<password>{{sender_password}}</password>
<controlid>{{$timestamp}}</controlid>
<uniqueid>false</uniqueid>
<dtdversion>3.0</dtdversion>
<includewhitespace>false</includewhitespace>
</control>
<operation>
<authentication>
<sessionid>{{temp_session_id}}</sessionid>
</authentication>
<content>
<function controlid="{{$guid}}">
<create_potransaction>
<transactiontype>Purchase Requisition</transactiontype>
<datecreated>
<year>2013</year>
<month>6</month>
<day>19</day>
</datecreated>
<vendorid>1001</vendorid>
<referenceno>1234</referenceno>
<vendordocno>vendordocno001</vendordocno>
<datedue>
<year>2013</year>
<month>6</month>
<day>20</day>
</datedue>
<payto>
<contactname>Jameson Company</contactname>
</payto>
<exchratetype>Intacct Daily Rate</exchratetype>
<customfields/>
<potransitems>
<potransitem>
<itemid>75300GL</itemid>
<quantity>100</quantity>
<unit>Each</unit>
<price>1</price>
<locationid>MGMT-US</locationid>
<departmentid>IT</departmentid>
</potransitem>
</potransitems>
</create_potransaction>
</function>
</content>
</operation>
</request>
Thank you in advance.
You can download the Postman collection file (API) from the developer docs.
And then just refer to Purchasing/Purchasing Transactions/Create Transaction (Legacy).
You can change the body (SOAP) content.
I'm sure you can manage it.
In IdP definition that the bundle uses, among other things, to generate AuthnRequest:
HOW/WHERE do I specify that I want the AuthnRequest signed e.g. with ECDSA-SHA256?
Do I have to override a factory service to achieve that?
<?xml version="1.0"?>
<md:EntityDescriptor
xmlns:mdalg="urn:oasis:names:tc:SAML:metadata:algsupport"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
entityID="some-entity">
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
<md:KeyDescriptor use="signing">
<mdalg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:X509Data>
I tried adding mdalg:SigningMethod and ds:SignatureMethod, as above, but I don't really know what I'm doing, as the config schema is not really well-defined in the documentation.
It seems like your placement of mdalg:SigningMethod is wrong. It is an extension to the original SAML2 standard and as such needs to live in an block. Take this as hearsay from me as I don't actually use that myself.
Here is the mailing list post regarding simpleSAMLphp software, and credit for the content goes to Peter Schober:
https://groups.google.com/forum/#!msg/simplesamlphp/HSdZXaYUuRI/bdz7mQJLBgAJ
An example of the placement in the XML is in there.
we are creating users in WSO2 via multiple identity providers (mostly with ADFS backends). We are mapping the UPNs into the subject on ADFS side and expected to get user ids like user#domain on WSO2 side (using just-in-time provisioning. An example SAML response looks like this:
<Subject>
<NameID>user#domain.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_d685e02e861d57cbf40c2a2af996f920" NotOnOrAfter="2018-12-04T15:32:47.404Z" Recipient="https://ourdomain.de/commonauth"/>
</SubjectConfirmation>
</Subject>
<Conditions>
<AudienceRestriction>
<Audience>ourdomain.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="Givenname">
<AttributeValue>adfsFirsname</AttributeValue>
</Attribute>
<Attribute Name="Lastname">
<AttributeValue>adfsLastname</AttributeValue>
</Attribute>
<Attribute Name="Role">
<AttributeValue>domain-user</AttributeValue>
<AttributeValue>admin</AttributeValue>
<AttributeValue>test</AttributeValue>
</Attribute>
<Attribute Name="username">
<AttributeValue>test</AttributeValue>
</Attribute>
<Attribute Name="mail">
<AttributeValue>user#domain.de</AttributeValue>
</Attribute>
</AttributeStatement>
</Conditions>
The problem is, that on WSO2 side we just get user as the userid and not the expected user#domain. Doesn't matter how we configure the mapping, the last #stuff gets cutted. Does anybody know, how to configure this, to get the complete user#domain as userid in WSO2?
Hope you can help me!
By default, WSO2 products will take username as #. That's why the #stuff part of the username was removed. If you want to use email as the username you need to configure. Here is the detailed documentation
Then the username will be treated as user#domain#tenentDomain. For the super tenant, you don't need to the #tenentDomain.
I actually managed to create a custom-claim-dialog on ADFS side, which manipulates the claim to contain one more #-symbol. This forces WSOIS to do what I want. Not the most beautiful solution, but it works for now...
saml20.implementation.SAMLFeedbackException: The response from the identity provider is not valid.
Trying to configure SAML2.0 using WSO2 5.4.1 Identity Server
Here is the Metadata file from WSO2 IS.
<?xml version="1.0" encoding="UTF-8"?><EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="localhost">
<IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
validUntil="2018-02-28T06:02:51.018Z"><KeyDescriptor use="signing"><KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#"><X509Data>
<X509Certificate>
MIIDSTCCAjGgAwIBAgIEAoLQ/TANBgkqhki....WCCq4ZuXl6wVsUz1iE61suO5yWi8=
</X509Certificate></X509Data></KeyInfo></KeyDescriptor><SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://localhost:9443/samlsso"
ResponseLocation="https://localhost:9443/samlsso"/>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-
format:unspecified</NameIDFormat><SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://localhost:9443/samlsso"/><SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://localhost:9443/samlsso"/></IDPSSODescriptor>
</EntityDescriptor>
Below file is SP generated from SAML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor entityID="http://localhost:7337/"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIDNjCCAh6gAwIBAgI....7YzPhQmQo7pVpn1YLvlNk
IJyZ9RkmZyI+h6ayztkOgc+scflN/j2fdDOufg==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
Redirect" Location="http://localhost:7337/SSO/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" Location="http://localhost:7337/SSO/logout"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://localhost:7337/SSO/assertion" index="1"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="http://localhost:7337/SSO/assertion" index="2"/>
</md:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">NNN</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">NNN</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en">www.xyz.com</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="administrative">
<md:GivenName>Test</md:GivenName>
<md:SurName>K</md:SurName>
<md:EmailAddress>test.k#gmail.com</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>
When I am running application it is redirecting me to wso2 login page. After giving username and password and on click on Login button I'm getting this error.
Finally I got it after lot of struggle and working properly.
I was missing a check box to check under SAML2 Web SSO Configuration, see the image below
I am really having a hard time finding a tutorial that can validate an xml signature using cxf.
I have a signed xml request like this: (NOTE: Signature value, digest value and X509 certificates are dummy values)
<?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ns="http://namespaces.gsma.org/esim-messaging/1">
<soap:Header/>
<soap:Body>
<ns:Request>
<ns:ParentNode>
<ns:TobeSignedInfo>
<ns:id>010203</ns:id>
<ns:oid>1.3.6.1.4.1.31746</ns:oid>
</ns:TobeSignedInfo>
<ns:SampleAdditionalProperties>
<ns:Property key="myProperty" value="aValue"/>
</ns:SampleAdditionalProperties>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>rE7suDc1EdUOJx6auQsTp8kGfZEe+pq2zaDvsKDMc/A=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
NXwOjw6ZT3NJRGqOluY8lF5/dkrTE89OjgB3z+kI4qmnTka0/hU6y9uihiRsrP+BZAMowhbwnPfy
ThEmTvMr0GGVB/w2pp0635Y8R672KNxZf2j48yFuz6ksyC5eBXVRAEswAt9lRh2ikcC9sULzLnSr
eA6rHNWiEm5v8OH708uZ/GWq4NlxQc8oLkrR634OY53ghPr2K+84vN99yxtGzYDHlTEFFJAyTqif
aUjYEQqcszKcbvf/XvriNcjHlk3kM8AwaQMePngxJatY3rlYWbykZhmwdqBgWrknRkjr5GAWVPEU
Q3aRlfbRYi66LV0UeGrzkinV2z5pwmBNxqc9GNnWMsvq0sWyF0BLSDY7yIz4HZVaeySytmZC21fI
PktCIfv+NRmOtFznkg3utX27Iwmc4kYGfeBXxmPMLOIkhf3dItOtV/8KNA4jW5dJNxnOEXiVXEV+
FJZbeAIet4wBvAfQb6QXcrfuwBp2kCmoYtmObH5Y+AgEf5KxPiGb1kLX
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIExDCCAywCCQC0bmU6MB8PuTANBgkqhkiG9w0BAQUFADCBozELMAkGA1UEBhMCUEgxEDAOBgNV
BAgTB0J1ZW5kaWExDzANBgNVBAcTBk1ha2F0aTEeMBwGA1UEChMVT2JlcnRodXIgVGVjaG5vbG9n
aWVzMSEwHwYDVQQLExhSZXNlYXJjaCBhbmQgRGV2ZWxvcG1lbnQxCzAJBgNVBAMTAk9UMSEwHwYJ
KoZIhvcNAQkBFhJlbWFpbEBvYmVydGh1ci5jb20wHhcNMTQxMDI1MDgzMzE5WhcNMTUxMDI1MDgz
MzE5WjCBozELMAkGA1UEBhMCUEgxEDAOBgNVBAgTB0J1ZW5kaWExDzANBgNVBAcTBk1ha2F0aTEe
MBwGA1UEChMVT2JlcnRodXIgVGVjaG5vbG9naWVzMSEwHwYDVQQLExhSZXNlYXJjaCBhbmQgRGV2
ZWxvcG1lbnQxCzAJBgNVBAMTAk9UMSEwHwYJKoZIhvcNAQkBFhJlbWFpbEBvYmVydGh1ci5jb20w
ggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDEaJeQaBruoMMG5LEdLc6D4aQq/4IXc6tk
kbEyO+2o3Ey3dU/WFSS7DNy86DKPWTG0VKinpFinwic+Be+A36K/eei8wyyv2YuhI1UuKWPsvmkV
mb/klra899jKvid1Jd0oMG8ViQGkpveYdoAfg5IR9k2NSgV1cn3ab26CmwwIpbDuPcMhW0bEXxG+
El67hrLQqpDjIuWRpbxs5prBdG4V79NrR6Pu1goLq9FmHsmKujPAu1gSnNmx61rab8zzVcEG19Fd
huG7ysilzDSeo2YTKs7Lzwp4Zu94T+IJYHYrV4iiB4jVLO7IQCUKB3T4y+9VYHI1fhasRGB1t8eR
CScsKg8IvtMMwjvKv4XK0EdBaLADzvpRVGAiV1hlo3sJ+D+tr/gkJ/ElVjC/90gIVxESwg5XQtPG
kQImde6GDZquEcT5URyvkq/WuMu+3J4NUSMpHDXeel2R8UkiSXs5ONxRyT3Ai3IjXUFhO9EGjFpe
eM1gqSYx3l6DyPSBF1rKHmkCAwEAATANBgkqhkiG9w0BAQUFAAOCAYEAaDkvLk/tzIMJA/3q2zJL
M+N5cPc+OVG8kPJK3aMInXciZRrY+uSyTflVaOpJJu038fN07kMzQePDyRJQENOZK0JsDz2bX1h5
6Z03b34/UdgFR5z3NC++iQNbBFaXjsfcAo45UgEgn7wPdqXQ8bdViHakmCMG43vPzLgp2ZSK0GMt
Pt1Q2qnbWz04Gkjog284RZZ4mpxSA3g8sVypoDTjw3HJhNRCPjq+tTXkOqWK4nNJH5tbwqq9uUjJ
6nTISN5WJ3OIvdLejPNmjMBBcaGVmFkGIBqlfyMZ+SuJiqMJfW/Ccqf640U3tyZDJNeTxMmaqerE
mnihf+sIdPf2RfwbdBPiHdLmmU65yi89b6Bz
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</ns:ParentNode>
</ns:Request>
</soap:Body>
</soap:Envelope>
How can I validate signature using cxf? I saw an implementation of WSPolicy and WSS4JInterceptors and it think it is not fit for this situation because the request doesn't have <wsse:Security> tag. Any thoughts are very much welcome.. Thanks in advance
The WS-Security standard mandates that XML Signature must be in the security header of the request (and not in the SOAP Body as per your example). So your best bet is to grab the SOAP Body (e.g. in a SOAP Handler), and use the Apache Santuario API to validate the signature yourself. Here is some sample code that shows you how to do the latter:
https://github.com/coheigea/testcases/blob/master/apache/santuario/santuario-xml-signature/src/test/java/org/apache/coheigea/santuario/xmlsignature/SignatureDOMTest.java
Colm.