The response from the identity provider is not valid - saml-2.0

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

Related

oracle apex 18 saml authentication with external identity provider

I am figuring out the way to use a third party identity provider for apex SSO authentication. Almost i am done with help of SAML SSO
Here is my metadata file by identity provider
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="u2ecyBkedSUsxVldsmYW27kONOp" cacheDuration="PT1440M" entityID="ps.trivadis.com">
<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="#u2ecyBkedSUsxVldsmYW27kONOp">
<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>Q0tFZzytRiz4POfzapmQCAOYMGdQ4s62D8U2K7YMP4Y=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
F+/8hUvaF+gqud3lt6Ua2BIPcrgdlMyMlghBwQ56yy0mcYv7fkxYlDys/8Ae7Lc6o05aGWesg0/m AeyJXZRwDOjuoeNPKvEK63J2xcPpJthN2XVyVdnfb5owAUuwSjysvMFLl8PQyN2Zoe6iOPXsPEJD PTQ7L2JRcM+WkgPGqxa/I8A4A+odK7BLSy4yVIzkrV3XD7NnQ0uiy7BbyFsPla+LGY08mwwAQhT9 Fe5Om4dWduckDP01JO8PJmdbELwkI5XmtQEsZoPbJsZ4AcjNJjX+5Uzm+CQep1BaxtU7xWisHrhh qd2JC76CJX5FMuyAnCaSqY5WHdBZ9CS0RaA5Fg==
</ds:SignatureValue>
</ds:Signature>
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIC/DCCAeSgAwIBAgIGAW1jcutSMA0GCSqGSIb3DQEBCwUAMD8xCzAJBgNVBAYTAkNIMRQwEgYDVQQKEwtUcml2YWRpcyBBRzEaMBgGA1UEAxMRZnMtdGVzdC52ZXJ0dW0uY2gwHhcNMTkwOTI0MTMyNTM4WhcNMjkwOTIxMTMyNTM4WjA/MQswCQYDVQQGEwJDSDEUMBIGA1UEChMLVHJpdmFkaXMgQUcxGjAYBgNVBAMTEWZzLXRlc3QudmVydHVtLmNoMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiwEI+qomPi0q8KCh6dLvmdZTbbN/R2uGaUgLZ7AgC/zYpEo1yX6FOpkZi2FK8x55B04NSWAVyF6YxPS2365Bm9aiWXdBLhs6mJJ46SjmuhTEPKWGL2lX7mPDamD5RR7FgNzj6ZM6f7S0Rl2jBoYt8eonYqbD+BcPX2F8YDlUWQfEuAdet7U+IZuE96r885QJS3Fx4CZ1/+IUk9kbKg9BZTutaz30TxGYQ5yC0GGFylMT4YbUA9SRiHeyOZdIiV0c6IzMF50d2VbBd+zcJdfF4Vi0je+G+TdvObJ0B14SVPyXwjBWRXuWsaY9BLIiHJD+DHAafcWpBb4SJWk+QfIVWQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAZBV9Hlfc3YrY/uCMelb+P8wVbnJbhONkTZsI+775FT+mk1cGZMEyUoItcwZg3eFOKWtykpujCPYoqandCvDu0Me6BLDCtUTx+KZrbwJ/xJyKVqWay53hrkcJHGzAv1ZJ5GtIcPpQCH9EYDC6GcmFSYaiJcNHB+TKtgxjyXTvDzuU1v4qsLQQVC0qlKUbyErYvdv7doqn7MnIMTYafJDZwiPh6phXZTswjN47Fkj32Ekt0zOC2oX4uEPTBxk6zCGIIcLsr3Sbns8kbHRcMWRaGUo8wryCDM99HBuwU+QArAqYGEsgZ3sEmEmICeshM/I5jkUHIj/Y+FVgdJqHo35iy
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://fs.trivadis.com/idp/SSO.saml2"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://fs.trivadis.com/idp/SSO.saml2"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="sn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="memberOf" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="userPrincipalName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="SAML_NAME_FORMAT" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>
</md:IDPSSODescriptor>
<md:ContactPerson contactType="administrative"/>
</md:EntityDescriptor>
i have follwed the simple steps as mention in the above link . but still i am not succeeded or actually logged into the apex via third party identity provider. Please let me know if you want to know some additional info about this setup i will share.
Your link doesn't work for me...not sure what you're trying to set up.
We have SAML2 authentication working with Apex via mod_auth_mellon for Apache (which just went out of support by the creator, but is still in most repos). Set it up to do SAML2 authentication and set an HTTP header with the username, and have Apex Authentication Scheme check the same header to pull in the username. Works well.

xmlsec1 saml signing: failed to find default node with name="Signature"

I am having a bit of trouble signing the following saml message:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://sp/sso/assert" ID="id-qOKj7lEjHF9LLlTjt" InResponseTo="_cd59dfa2245177f214bfc5252c873e702ad29640c3" IssueInstant="2018-07-06T07:34:48Z" Version="2.0">
<saml2:Issuer>http://myidp/sso</saml2:Issuer>
<ds:Signature>
<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="#_50247aab9621ee91aaca836e20de20dc">
<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/>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue/>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIC8jCCAlugAwIBAgIJAJHg2V5J31I8MA.....</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="id-RytehFWT2t5Bem6UH" IssueInstant="2018-07-06T07:34:48Z" Version="2.0">
<saml2:Issuer>http://myidp/sso</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">test#test.com</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_cd59dfa2245177f214bfc5252c873e702ad29640c3" NotOnOrAfter="2018-07-06T07:34:48Z" Recipient="https://sp/assert"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2018-07-06T07:34:48Z" NotOnOrAfter="2018-07-08T08:52:24.242Z">
<saml2:AudienceRestriction>
<saml2:Audience>test_audience</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2018-07-06T07:34:48Z" SessionIndex="_72c6639cdbf65c0b2eed63847990b13a">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>
Whenever I launch the command to sign using xmlsec1, I get the following message:
Error: failed to find default node with name="Signature"
Error: failed to load template "/tmp/test.xml"
Error: failed to sign file "/tmp/test.xml"
As you can see in my SAML message, I already have a Signature tag, and I checked that my XML is valid, so I am a bit stuck right now. Can anyone locate my problem?
It turns out I was missing the signature node in the Assertion part of the message, you need to have both if you want to sign the message AND the assertion.

Where is a Websphere Portlet Application 'Title' stored

I'm using the Websphere (6.1) Portal Administration page. I expand the 'Portlet Management menu and click on 'Applications'. I see a list of the portlet applications but some of them show "Application Name not available for this Application" in the title column. Where is a portal application 'Application Name' supposed to be stored in order to be shown in this list?
That would be the id attribute of the portlet-app element within the portlet.xml. In the example below this would be "com.test.portlets.testportlet.TestPortlet".
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
id="com.test.portlets.testportlet.TestPortlet">
<portlet>
<portlet-name>TestPortlet</portlet-name>
<display-name>TestPortlet</display-name>
<display-name xml:lang="en">TestPortlet</display-name>
<portlet-class>com.test.portlets.testportlet.TestPortlet</portlet-class>
<init-param>
<name>wps.markup</name>
<value>html</value>
</init-param>
<expiration-cache>0</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
<resource-bundle>com.test.portlets.testportlet.nl.TestPortletResource</resource-bundle>
<portlet-info>
<title>TestPortlet</title>
<short-title>TestPortlet</short-title>
<keywords>TestPortlet</keywords>
</portlet-info>
</portlet>
</portlet-app>

Azure AD SAML2 response: System.Security.Cryptography not supporting http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

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>

How to verify XML Signature using CXF/JAXWS?

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.

Resources