cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Validate SAML token failed
Date Fri, 15 May 2020 09:16:42 GMT
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 <ignis@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 <ignis@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 <ignis@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 <ignis@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
> >>>>>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message