Hello! Its SOLVED! there were multiple errors: - typo in the keystore filename, - the Cryptoproperties must be in a property file, what need to put under WEB-INF/classes/ - the SignatureUsername is the alias in the keystore - must be a password callback handler for the password to the private key (and its hard to config thru the config files)
thanx Csaba On 2018.01.26. 18:49, Tóth Csaba wrote: > Hello! > I'm now very confused: > > I have this config file: > > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns="http://www.springframework.org/schema/beans"; > xmlns:cxf="http://cxf.apache.org/core"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:sec="http://cxf.apache.org/configuration/security"; > xmlns:http="http://cxf.apache.org/transports/http/configuration"; > xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"; > xmlns:jaxws="http://cxf.apache.org/jaxws"; > xmlns:util="http://www.springframework.org/schema/util"; > xmlns:soap="http://cxf.apache.org/bindings/soap"; > xsi:schemaLocation="http://cxf.apache.org/core > http://cxf.apache.org/schemas/core.xsd > http://cxf.apache.org/configuration/security > http://cxf.apache.org/schemas/configuration/security.xsd > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > http://cxf.apache.org/transports/http-jetty/configuration > http://cxf.apache.org/schemas/configuration/http-jetty.xsd > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-4.2.xsd > http://www.springframework.org/schema/util > http://www.springframework.org/schema/util/spring-util-4.2.xsd > http://cxf.apache.org/bindings/soap > http://cxf.apache.org/schemas/configuration/soap.xsd";> > > <bean id="defaultTokenStore" > class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore"> > </bean> > <bean id="cryptoProperties" class="java.util.Properties"> > <constructor-arg> > <props> > <prop > key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop> > <prop > key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop> > </props> > </constructor-arg> > </bean> > > <bean id="utSTSProperties" > class="org.apache.cxf.sts.StaticSTSProperties"> > <property name="SignatureCryptoProperties" ref="cryptoProperties"/> > <property name="issuer" value="issuer"/> > <property name="signatureUsername" value="signature"/> > </bean> > > <bean id="utService" class="org.apache.cxf.sts.service.StaticService"> > <property name="endpoints" value="http://localhost: xxxx > /services/SecurityTokenServiceProvider" /> > </bean> > > <bean id="utSCTSamlTokenProvider" > class="org.apache.cxf.sts.token.provider.SAMLTokenProvider"> > </bean> > > <util:list id="utTokenProviders"> > <ref bean="utSCTSamlTokenProvider"/> > </util:list> > > <bean id="utIssueDelegate" class=" package .TokenIssueOperation"> > <property name="tokenProviders" ref="utTokenProviders"/> > <property name="services" ref="utService" /> > <property name="stsProperties" ref="utSTSProperties" /> > <property name="tokenStore" ref="defaultTokenStore"/> > </bean> > > <bean id="utSTSProviderBean" class=" package > .SecurityTokenServiceProvider"> > <property name="issueOperation" ref="utIssueDelegate" /> > </bean> > <!-- > <bean id="utSTSProviderBean" > class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider"> > <property name="issueOperation" ref="utIssueDelegate" /> > </bean> > --> > > <jaxws:endpoint > xmlns:tns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"; > id="securitytokenserviceprovider" implementor="#utSTSProviderBean" > wsdlLocation="WEB-INF/wsdl/ws-trust-1.4-service.wsdl" > endpointName="tns:UT_Port" > serviceName="tns:SecurityTokenService" > address="/SecurityTokenServiceProvider"> > <jaxws:properties> > > <entry key="security.return.security.error" value="true" /> > <entry key="security.validate.audience-restriction" > value="false" /> > <entry key="security.signature.properties"> > <bean id="signatureCryptoProperties" > class="java.util.Properties"> > <constructor-arg> > <props> > <prop > key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop> > <prop > key="org.apache.ws.security.crypto.merlin.keystore.password">.....</prop> > <prop > key="org.apache.ws.security.crypto.merlin.file">key/key.jks</prop> > </props> > </constructor-arg> > </bean> > </entry> > <entry key="ws-security.saml2.validator"> > <bean > class="org.apache.cxf.ws.security.trust.STSTokenValidator"/> > </entry> > </jaxws:properties> > <jaxws:binding> > <soap:soapBinding mtomEnabled="true" version="1.2" /> > </jaxws:binding> > </jaxws:endpoint> > </beans> > > the keystore is under WEB-INF, it cointains the cert from the incomming > Cert. > > all help thanks. > > Csaba > > On 2018.01.26. 15:40, Colm O hEigeartaigh wrote: >> OK so it appears the problems with the STS issuing the token have been >> fixed? The errors are from the STSSamlAssertionValidator, which is supposed >> to be used on the service side. It tries to validate the Signature locally >> on the token, and if it fails it dispatches the token to the STS for >> validation, which is why you're seeing an error about STSClient. >> >> What behaviour are you expecting on the service side? Normally the >> STSSamlAssertionValidator >> is not configured, because you have the CA cert of the STS in the service >> keystore and it can validate the certificate locally. Is the STS cert (or >> CA cert) in your crypto properties file pointing to by the >> security.signature.properties configuration variable on the service side? >> >> Colm. >> >> On Fri, Jan 26, 2018 at 11:56 AM, Tóth Csaba <[email protected]> wrote: >> >>> Hello! >>> (Sorry for the wrong address) >>> >>> It's go forward with little steps. >>> now I get this error: >>> jan. 26, 2018 12:42:21 DU >>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator >>> verifySignedAssertion >>> WARNING: Local trust verification of SAML assertion failed: Error during >>> certificate path validation: No trusted certs found >>> org.apache.wss4j.common.ext.WSSecurityException: Error during >>> certificate path validation: No trusted certs found >>> at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:829) >>> at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:919) >>> at >>> org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts( >>> SignatureTrustValidator.java:109) >>> at >>> org.apache.wss4j.dom.validate.SignatureTrustValidator.validate( >>> SignatureTrustValidator.java:64) >>> at >>> org.apache.wss4j.dom.validate.SamlAssertionValidator. >>> verifySignedAssertion(SamlAssertionValidator.java:214) >>> at >>> org.apache.cxf.ws.security.trust.STSSamlAssertionValidator. >>> verifySignedAssertion(STSSamlAssertionValidator.java:68) >>> >>> I get the certification from the SAML, and put into the keystore what i >>> already setup (and put under the WEB-INF/classes/key directory >>> >>> the strange thing, the next error come about: >>> jan. 26, 2018 12:42:24 DU org.apache.cxf.phase.PhaseInterceptorChain >>> doDefaultLogging >>> WARNING: Interceptor for >>> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService >>> has thrown exception, unwinding now >>> org.apache.cxf.ws.security.trust.TrustException: The STSClient is not >>> configured with either a location or wsdlLocation property >>> at >>> org.apache.cxf.ws.security.trust.AbstractSTSClient.createClient( >>> AbstractSTSClient.java:673) >>> at >>> org.apache.cxf.ws.security.trust.AbstractSTSClient. >>> validate(AbstractSTSClient.java:1101) >>> at >>> org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken( >>> STSClient.java:105) >>> >>> What STSClient? why want to create a client? >>> in the cxf settings no "client" string is found >>> >>> Thanx >>> Csaba >>> >>> On 2018.01.25. 15:48, Colm O hEigeartaigh wrote: >>>> Please reply to the CXF mailing list and not me directly...the problem >>>> is that the SAML Assertion is getting validated before it hits the >>>> STS, so you need to make a reference to the signature properties as a >>>> JAX-WS property of the endpoint. For example: >>>> >>>> https://github.com/apache/cxf/blob/6a3f97e9f0d02eef72bf10c266d444 >>> ec3af78bf5/services/sts/systests/basic/src/test/resources/org/apache/cxf/ >>> systest/sts/transport/cxf-service.xml#L44 >>>> On Thu, Jan 25, 2018 at 2:38 PM, Tóth Csaba <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hello! >>>> this is the full trace: >>>> >>>> jan. 25, 2018 2:17:13 DU org.apache.cxf.phase.PhaseInterceptorChain >>>> doDefaultLogging >>>> WARNING: Interceptor for >>>> {http://docs.oasis-open.org/ws-sx/ws-trust/200512/} >>> SecurityTokenService >>>> <http://docs.oasis-open.org/ws-sx/ws-trust/200512/% >>> 7DSecurityTokenService> >>>> has thrown exception, unwinding now >>>> org.apache.cxf.binding.soap.SoapFault: No crypto property file >>>> supplied >>>> for signature >>>> at >>>> org.apache.cxf.ws.security.wss4j.WSS4JUtils. >>> createSoapFault(WSS4JUtils.java:236) >>>> at >>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor. >>> handleMessageInternal(WSS4JInInterceptor.java:340) >>>> at >>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage( >>> WSS4JInInterceptor.java:175) >>>> at >>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor. >>> handleMessage(PolicyBasedWSS4JInInterceptor.java:79) >>>> at >>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor. >>> handleMessage(PolicyBasedWSS4JInInterceptor.java:66) >>>> at >>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( >>> PhaseInterceptorChain.java:308) >>>> at >>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage( >>> ChainInitiationObserver.java:121) >>>> at >>>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke( >>> AbstractHTTPDestination.java:267) >>>> at >>>> org.apache.cxf.transport.servlet.ServletController. >>> invokeDestination(ServletController.java:234) >>>> at >>>> org.apache.cxf.transport.servlet.ServletController. >>> invoke(ServletController.java:208) >>>> at >>>> org.apache.cxf.transport.servlet.ServletController. >>> invoke(ServletController.java:160) >>>> at >>>> org.apache.cxf.transport.servlet.CXFNonSpringServlet. >>> invoke(CXFNonSpringServlet.java:191) >>>> at >>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest( >>> AbstractHTTPServlet.java:301) >>>> at >>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet. >>> doPost(AbstractHTTPServlet.java:220) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) >>>> at >>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet. >>> service(AbstractHTTPServlet.java:276) >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( >>> ApplicationFilterChain.java:231) >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter( >>> ApplicationFilterChain.java:166) >>>> at >>>> org.apache.tomcat.websocket.server.WsFilter.doFilter( >>> WsFilter.java:52) >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( >>> ApplicationFilterChain.java:193) >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter( >>> ApplicationFilterChain.java:166) >>>> at >>>> org.apache.catalina.core.StandardWrapperValve.invoke( >>> StandardWrapperValve.java:198) >>>> at >>>> org.apache.catalina.core.StandardContextValve.invoke( >>> StandardContextValve.java:96) >>>> at >>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke( >>> AuthenticatorBase.java:504) >>>> at >>>> org.apache.catalina.core.StandardHostValve.invoke( >>> StandardHostValve.java:140) >>>> at >>>> org.apache.catalina.valves.ErrorReportValve.invoke( >>> ErrorReportValve.java:81) >>>> at >>>> org.apache.catalina.valves.AbstractAccessLogValve.invoke( >>> AbstractAccessLogValve.java:650) >>>> at >>>> org.apache.catalina.core.StandardEngineValve.invoke( >>> StandardEngineValve.java:87) >>>> at >>>> org.apache.catalina.connector.CoyoteAdapter.service( >>> CoyoteAdapter.java:342) >>>> at >>>> org.apache.coyote.http11.Http11Processor.service( >>> Http11Processor.java:803) >>>> at >>>> org.apache.coyote.AbstractProcessorLight.process( >>> AbstractProcessorLight.java:66) >>>> at >>>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process( >>> AbstractProtocol.java:790) >>>> at >>>> org.apache.tomcat.util.net >>>> <http://org.apache.tomcat.util.net>.NioEndpoint$ >>> SocketProcessor.doRun(NioEndpoint.java:1459) >>>> at >>>> org.apache.tomcat.util.net >>>> <http://org.apache.tomcat.util.net>.SocketProcessorBase. >>> run(SocketProcessorBase.java:49) >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>> Source) >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>> Source) >>>> at >>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run( >>> TaskThread.java:61) >>>> at java.lang.Thread.run(Unknown Source) >>>> >>>> Csaba >>>> >>>> On 2018.01.25. 15 <tel:2018.01.25.%2015>:32, Colm O hEigeartaigh >>>> wrote: >>>> > What's the full stack-trace? >>>> > >>>> > On Thu, Jan 25, 2018 at 1:44 PM, Tóth Csaba <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> > >>>> >> Hello! >>>> >> Yes, after I deleted it, its begin to parse the SAML. >>>> >> the next error is about the SigVerCrypto is empty at the >>>> >> SignatureTrustValidator.validate step. >>>> >> (get from the RequestData.sigVerCrypto) >>>> >> >>>> >> I set up the thing: >>>> >> >>>> >> <bean id="cryptoProperties" class="java.util.Properties"> >>>> >> <constructor-arg> >>>> >> <props> >>>> >> <prop >>>> >> key="org.apache.ws.security.crypto.provider">org.apache. >>>> >> ws.security.components.crypto.Merlin</prop> >>>> >> <prop >>>> >> key="org.apache.ws.security.crypto.merlin.keystore.type"> >>> jks</prop> >>>> >> <prop >>>> >> key="org.apache.ws.security.crypto.merlin.keystore.password"> >>>> .... </prop> >>>> >> <prop >>>> >> key="org.apache.ws.security.crypto.merlin.file">key/key. >>> jks</prop> >>>> >> </props> >>>> >> </constructor-arg> >>>> >> </bean> >>>> >> <bean id="utSTSProperties" >>>> >> class="org.apache.cxf.sts.StaticSTSProperties"> >>>> >> <property name="SignatureCryptoProperties" >>>> >> ref="cryptoProperties"/> >>>> >> .... >>>> >> </bean> >>>> >> >>>> >> and put the keyfile under the WEB-INF/classes/key >>>> >> (in the keyfile the keys for signing the new SAML) >>>> >> >>>> >> Thanx >>>> >> Csaba >>>> >> >>>> >> >>>> >> On 2018.01.25. 13 <tel:2018.01.25.%2013>:40, Colm O >>>> hEigeartaigh wrote: >>>> >>> Do you mean that there was a "saml2p:Status" element in the >>>> security >>>> >> header >>>> >>> before the Assertion? If so then this is not valid, only the SAML >>>> >> Assertion >>>> >>> should be there. >>>> >>> >>>> >>> Colm. >>>> >>> >>>> >>> On Thu, Jan 25, 2018 at 8:47 AM, Tóth Csaba <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>> >>>> >>>> Hello! >>>> >>>> >>>> >>>> I dig deeper in the code: >>>> >>>> The problem with the SAML was: >>>> >>>> In the securty element contains not only the SAML, its >>>> contains before >>>> >>>> the SAML an >>>> >>>> <saml2:Issuer> and an <saml2p:Status> element >>>> >>>> (in his case The same is not processed) >>>> >>>> >>>> >>>> If I delete it, its go thru the SAML validator >>>> >>>> >>>> >>>> Csaba >>>> >>>> >>>> >>>> On 2018.01.24. 19 <tel:2018.01.24.%2019>:25, Tóth Csaba wrote: >>>> >>>>> Hello! >>>> >>>>> Thanx. I changed the namespace, but not helped. >>>> >>>>> >>>> >>>>> The DefaultSubjectProvider cant retrieve the subject from >>>> this SAML: >>>> >>>>> >>>> >>>>> <saml2:Assertion ID="..." IssueInstant="..." Version="2.0" >>>> >>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> >>>> >>>>> >>>> >>>>> <saml2:Subject> >>>> >>>>> <saml2:NameID >>>> >>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format: >>>> >>>> persistent">[name]</saml2:NameID> >>>> >>>>> <saml2:SubjectConfirmation >>>> >>>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> >>>> >>>>> <saml2:SubjectConfirmationData >>>> >>>>> InResponseTo="_9c7644ce0fb93649cd2ca77bb9b5e6db22f68b52a9" >>>> >>>>> NotOnOrAfter="2018-01-24T18:06:33.305Z"/> >>>> >>>>> </saml2:SubjectConfirmation> >>>> >>>>> </saml2:Subject> >>>> >>>>> >>>> >>>>> </saml2:Assertion> >>>> >>>>> >>>> >>>>> But I get an error, because the subject is null >>>> >>>>> (At this point I cant change the SAML in the request) >>>> >>>>> >>>> >>>>> Thanx >>>> >>>>> >>>> >>>>> Csaba >>>> >>>>> >>>> >>>>> On 2018.01.24. 10:55, Colm O hEigeartaigh wrote: >>>> >>>>>> The problem I think is that "http://schemas.xmlsoap.org/ >>>> >>>> ws/2003/06/secext" >>>> >>>>>> is not a standard WS-Security namespace, and hence CXF is not >>>> >> processing >>>> >>>>>> the message header at all. The correct WS-Security >>>> namespace for the >>>> >>>>>> security header is instead " >>>> >>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- >>>> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-> >>>> >>>> wssecurity-secext-1.0.xsd >>>> >>>>>> ". >>>> >>>>>> >>>> >>>>>> You could take a look at the CXF transformation feature to >>>> transform >>>> >> the >>>> >>>>>> namespace into the correct version (no idea if this will >>>> work or not): >>>> >>>>>> >>>> >>>>>> http://cxf.apache.org/docs/transformationfeature.html >>>> <http://cxf.apache.org/docs/transformationfeature.html> >>>> >>>>>> >>>> >>>>>> Colm. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>>> >>>> >>>>>>> Hello! >>>> >>>>>>> Its in the header: >>>> >>>>>>> ------------ >>>> >>>>>>> <soapenv:Envelope >>>> >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ >>>> <http://schemas.xmlsoap.org/soap/envelope/>" >>>> >>>>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512 >>>> <http://docs.oasis-open.org/ws-sx/ws-trust/200512>" >>>> >>>>>>> xmlns:a="http://www.w3.org/2005/08/addressing >>>> <http://www.w3.org/2005/08/addressing>"> >>>> >>>>>>> <soapenv:Header> >>>> >>>>>>> <wsse:Security xmlns:wsse="http://schemas. >>>> >>>> xmlsoap.org/ws/2003/06/secext >>>> <http://xmlsoap.org/ws/2003/06/secext>" >>>> >>>>>>> <saml:Assertion xmlns:saml="urn:oasis:names: >>>> >> tc:SAML:2.0:assertion" >>>> >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance >>>> <http://www.w3.org/2001/XMLSchema-instance>" >>>> >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema >>>> <http://www.w3.org/2001/XMLSchema>" >>>> >>>>>>> ID="pfxccb2f4f7-ca9c-3b5e-89b1-1d3c777400bc" Version="2.0" >>>> >>>>>>> IssueInstant="2014-07-17T01:01:48Z"> >>>> >>>>>>> >>>> >>>>>>> [assertion] >>>> >>>>>>> >>>> >>>>>>> </saml:Assertion> >>>> >>>>>>> >>>> >>>>>>> </wsse:Security> >>>> >>>>>>> </soapenv:Header> >>>> >>>>>>> <soapenv:Body> >>>> >>>>>>> <ns:RequestSecurityToken > >>>> >>>>>>> >>>> >>>>>>> <ns:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/ >>>> <http://docs.oasis-open.org/ws-sx/ws-trust/> >>>> >> 200512/Issue >>>> >>>>>>> </ns:RequestType> >>>> >>>>>>> >>>> >>>>>>> <ns:TokenType>http://docs.oasis-open.org/wss/oasis-wss- >>>> <http://docs.oasis-open.org/wss/oasis-wss-> >>>> >>>>>>> saml-token-profile-1.1#SAMLV2.0</ns:TokenType> >>>> >>>>>>> <ns7:AppliesTo xmlns:ns7="http://www.w3.org/ns/ws-policy >>>> <http://www.w3.org/ns/ws-policy>"> [url] >>>> >>>>>>> </ns7:AppliesTo> >>>> >>>>>>> <!-- >>>> >>>>>>> <ns:Claims Dialect="http://bag.admin.ch/ >>>> >> epr/2017/annex/5/addendum/2 >>>> >>>> "> >>>> >>>>>>> [claims need to process too ] >>>> >>>>>>> >>>> >>>>>>> </ns:Claims> >>>> >>>>>>> --> >>>> >>>>>>> </ns:RequestSecurityToken> >>>> >>>>>>> </soapenv:Body> >>>> >>>>>>> </soapenv:Envelope> >>>> >>>>>>> --------------------- >>>> >>>>>>> >>>> >>>>>>> Its look like easy task for the first look: >>>> >>>>>>> get a SAML in the header, full of attributes, and a >>>> request with >>>> >> other >>>> >>>>>>> attributes. >>>> >>>>>>> Validate some attributes, and all header attributes + claims >>>> >> attributes >>>> >>>>>>> put the new SAML token. >>>> >>>>>>> >>>> >>>>>>> but, about a week long, I google, read source code, google >>>> again, and >>>> >>>>>>> try to config the thing. >>>> >>>>>>> no good tutorial, no good documentation, no good >>>> description :( >>>> >>>>>>> >>>> >>>>>>> Csaba >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> On 2018.01.23. 18 <tel:2018.01.23.%2018>:08, Colm O >>>> hEigeartaigh wrote: >>>> >>>>>>>> What does the request look like, e.g. where is the SAML >>>> token in the >>>> >>>>>>>> request? Is it referred to directly in the SOAP Body? >>>> >>>>>>>> >>>> >>>>>>>> Colm. >>>> >>>>>>>> >>>> >>>>>>>> On Tue, Jan 23, 2018 at 4:37 PM, Tóth Csaba >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>>>>> >>>> >>>>>>>>> Hello! >>>> >>>>>>>>> >>>> >>>>>>>>> I'd like to parse the incomming SAML token to get the >>>> fields (user, >>>> >>>> etc) >>>> >>>>>>>>> and give it to the issuer. >>>> >>>>>>>>> I found, that is done in the >>>> >>>>>>>>> org.apache.cxf.sts.operation.TokenIssueOperation class but >>>> >>>>>>>>> stsProperties.getSamlRealmCodec() is always null in my >>>> code (how >>>> >>>> can i >>>> >>>>>>>>> set it, need to create a new one?) >>>> >>>>>>>>> but after in the fetchSAMLAssertionFromWSSecuri >>> tySAMLToken() >>>> >>>> function >>>> >>>>>>>>> List<WSSecurityEngineResult> engineResults = >>>> >>>> handlerResult.getResults(); >>>> >>>>>>>>> line give back an empty list. >>>> >>>>>>>>> >>>> >>>>>>>>> In the request there is an SAML token. >>>> >>>>>>>>> >>>> >>>>>>>>> I try to find some solution, but every example is >>>> working with the >>>> >>>>>>>>> usernametoken, and/or dont provide a valid cxf config xml. >>>> >>>>>>>>> >>>> >>>>>>>>> Thanx >>>> >>>>>>>>> Csaba >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >> >>>> > >>>> >>>> >>>> >>>> >>>> -- >>>> Colm O hEigeartaigh >>>> >>>> Talend Community Coder >>>> http://coders.talend.com >>> >
