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: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]> 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: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- >> 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 >>>> >>>> Colm. >>>> >>>> >>>> On Tue, Jan 23, 2018 at 6:19 PM, Tóth Csaba <[email protected]> wrote: >>>> >>>>> Hello! >>>>> Its in the header: >>>>> ------------ >>>>> <soapenv:Envelope >>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >>>>> xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"; >>>>> xmlns:a="http://www.w3.org/2005/08/addressing";> >>>>> <soapenv:Header> >>>>> <wsse:Security xmlns:wsse="http://schemas. >> 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"; >>>>> xmlns:xs="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/200512/Issue >>>>> </ns:RequestType> >>>>> >>>>> <ns:TokenType>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";> [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: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]> 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 fetchSAMLAssertionFromWSSecuritySAMLToken() >> 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 >>>>>>> >>>>>>> >> >
