Hi Arnaud, It's not a bug, as Fediz doesn't support signature verification on SAML Assertions without a KeyInfo to obtain the signing key/cert. If you need to support this scenario, please consider contributing a pull request. I think it could be supported by adding a new interface which would return a certificate used for signature validation, given a signed SAML Assertion. The default implementation could just return the cert in the KeyInfo. However another implementation could return one of the certs in the configured certificateStores.
Colm. On Tue, Jun 2, 2020 at 7:12 PM Arnaud Yahoo <[email protected]> wrote: > Hello, > > During a SAML authentication flow, it seems Fediz is throwning NPE when > signature is missing KeyInfo, which is supposed to be optional (if I > understand saml spec correctly). > > While processing this kind of signature > > <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="#dG09eAtYsmf1tfNVvs37uZdJd-u"> > <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>XI9dqpDtmdtCEnRBFxuoWoii1Mh5kFPIsTP/qkSCfB0=</ds:DigestValue> > </ds:Reference> > </ds:SignedInfo> > <ds:SignatureValue> > > QOwv36AiO9PKu4dTalBF9JoauSj6Sdc7/sirWuJLlUGNJGR29ZvnaH2vGwvYxCKR6DGhMGTh+ePB > > gt2qRkxaetjAQEnO71PXg24CVsCTZoNzLpsXRXRjw8K4/Jo8Lsv19gqkiD4hPRVyc/K70Op9e2pM > > kHF44yX/hwOgjn3A7B/c5cpcLsFyGgGBBkWKvTYV1kg4UY6C/O1ngR45h0QSiAc6bc4R26W4fbjl > > Q6JCo6sOGViVwbBsTmVSAtbEeEPdiWeXVc1raKA/Nfi6aKQmKhhkH4tkgR/4UwRoxnvcf47hKBx0 > 05g2is0osHh1PLrioChhxdV22Mnfv9aPGb6acQ== > </ds:SignatureValue> > </ds:Signature> > > The NPE is > > org.apache.cxf.fediz.core.processor.SAMLProcessorImpl.processSignInRequest > Failed to validate token > java.lang.NullPointerException > at > > org.apache.cxf.fediz.core.saml.SAMLTokenValidator.validateAndProcessToken(SAMLTokenValidator.java:107) > at > > org.apache.cxf.fediz.core.processor.SAMLProcessorImpl.processSignInRequest(SAMLProcessorImpl.java:203) > at > > org.apache.cxf.fediz.core.processor.SAMLProcessorImpl.processRequest(SAMLProcessorImpl.java:114) > at > > org.apache.cxf.fediz.core.handler.SigninHandler.processSigninRequest(SigninHandler.java:124) > at > > org.apache.cxf.fediz.core.handler.SigninHandler.handleRequest(SigninHandler.java:76) > at > > com.semarchy.tool.jee.tomcat.FederationAuthenticator.authenticate(FederationAuthenticator.java:140) > at > > org.apache.cxf.fediz.tomcat8.FederationAuthenticator.doAuthenticate(FederationAuthenticator.java:231) > at > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:633) > at > > org.apache.cxf.fediz.tomcat8.FederationAuthenticator.invoke(FederationAuthenticator.java:184) > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) > at > org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:747) > at > > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:688) > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) > at > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609) > at > > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) > at > > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818) > at > org.apache.tomcat.util.net > .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623) > at > org.apache.tomcat.util.net > .SocketProcessorBase.run(SocketProcessorBase.java:49) > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:748) > > Is it a bug ? or can I configure somthing to support this kind of > signature ? > > Kind Regards, > > Arnaud > > > > >
