Thank You!
Yes my trust setup working only a valid x509 certification.
Thanx!
Csba

On 2020-05-15 11:16, Colm O hEigeartaigh wrote:
I've created and fix this bug in WSS4J:
https://issues.apache.org/jira/browse/WSS-672

I'm not sure if it will fix your problem or not. Before this fix, it would
just get the first credential in the KeyInfo (the PublicKey in your case).
It looks like your trust setup is not working with PublicKey. With this fix
it will also grab any X.509 Certificates and use these as well for trust
verification.

Colm.

On Fri, May 15, 2020 at 8:11 AM Tóth Csaba <ig...@domen.hu> wrote:

Hello!
I found it:
At the org.apache.wss4j.common.saml.SAMLUtil.getCredentialFromKeyInfo(
          Element keyInfoElement,
          SAMLKeyInfoProcessor keyInfoProcessor,
          Crypto sigCrypto
      )
function
when parse the keyInfo element: If found a keyValue, dont search for
x509Data. (line 214) Its a bug or features?

Thanx
Csaba

On 2020-05-14 14:12, Colm O hEigeartaigh wrote:
I think you need to either turn on debug logging or do some debugging and
figure out what is going on with the trust validation process in WSS4J.

Colm.

On Thu, May 14, 2020 at 12:58 PM Tóth Csaba <ig...@domen.hu> wrote:

Ok,
In the request there is a x509 certification. After i copy it, and write
the BEGIN-END certification thing around it, the openssl can parse it,
and show it as an certification. So there is a valid x509 certification
inside the <KeyInfo> element inside the <X509Data> element
(inside the <X509Certificate> element)

Can the KeyName and KeyValue does the mess?

Thanx
Csaba

On 2020-05-14 13:39, Colm O hEigeartaigh wrote:
Well getCerts() returns null as there is no certificate in the
Assertion
KeyInfo, only a public key. getPublicKey() should not return null
though.
Bear in mind that this public key must be contained in the local trust
store (embedded in a certificate), or signature verification will fail.

Colm.

On Thu, May 14, 2020 at 12:19 PM Tóth Csaba <ig...@domen.hu> wrote:

Hello!
Sorry, maybe I was wrong: It is processed, without any error, (I dotn
have stack trace), but
inside the


org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.verifySignedAssertion
after the assertion.getSignatureKeyInfo().getCerts() I excepted an
X509Certificate[] (array, at least an empty one), but I get null.

So I think something is not processed well.

Thanx
Csaba

On 2020-05-14 13:12, Colm O hEigeartaigh wrote:
I imagine the problem is with the KeyValue, and not with the
signature
algorithm. Why you say it can't process the SAML, what is the
stacktrace
you are seeing?

Colm.

On Thu, May 14, 2020 at 12:05 PM Tóth Csaba <ig...@domen.hu> wrote:

Hello!
I have a system, what accept the request only with SAML token.
Its worked until the last request.
until now the SAML in the request:
<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/2000/09/xmldsig#rsa-sha1"/>
                             <ds:Reference URI=" ... ">
                                 <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#";>
                                         <ec:InclusiveNamespaces
PrefixList="xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#
"/>
                                     </ds:Transform>
                                 </ds:Transforms>
                                 <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                                 <ds:DigestValue> ...
</ds:DigestValue>
                             </ds:Reference>
                         </ds:SignedInfo>
                         <ds:SignatureValue> ... </ds:SignatureValue>
                         <ds:KeyInfo>
                             <ds:X509Data> ...
but the last request contain different structure:
                     <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>
                             <KeyName> ... </KeyName>
                             <KeyValue>
                                 <RSAKeyValue>
                                     <Modulus>
...
</Modulus>
                                     <Exponent>
...
</Exponent>
                                 </RSAKeyValue>
                             </KeyValue>
                             <X509Data>
I noticed two difference between the two request:
1 - one signed with rsa-sha1 the second with rsa-sha256
2 - the second contain <KeyName> and <keyvalue>
At the validation proccess, inside the


org.apache.cxf.ws.security.trust.STSSamlAssertionValidator.verifySignedAssertion:
the  SamlAssertionWrapper assertion has SAMLKeyInfo
(assertion.getSignatureKeyInfo() ) but the inside SAMLKeyInfo the
X509Certificate array is null
(not empty, simple null). I looking for the solution: why cant
process
the SAML?

Thanx
Csaba



Reply via email to