It's great that it's working for you, but the STS endpoint should not have a "ws-security.saml2.validator" pointing to the STSTokenValidator. The STSTokenValidator is used by a service to send a received SAML token off to an STS for validation. In your case, the validation is done locally, so you shouldn't need to specify "ws-security.saml2.validator" at all.
Colm. On Sun, Jan 28, 2018 at 8:59 AM, Tóth Csaba <[email protected]> wrote: > 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 > >>> > > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
