> I have verified fix for CXF-4357 and added comment to it. Please let me know if I need to close this ticket. Thanks.
No, it only closes after a release goes out that contains the fix. > Now client is able to send RST to STS, but STS(ADFS2.0) failed generating RSTR because of an empty <wst:Renewing>tag embedded inside > RST. ADFS does not support Token renewing. Why do we have Renewing tag inside issue request? The Renewing tag simply requests that an issued token that can be renewed. You could try setting the following property "allowRenewing" to "false" on the STSClient. That will send a request with "<wst:Renewing Allow="false/>". I'm not sure if ADFS 2.0 will reject this or not. Let me know if it works or not. Colm. On Wed, Jun 6, 2012 at 4:26 PM, Gina Choi <[email protected]> wrote: > Hi Colm, > > I have verified fix for CXF-4357 and added comment to it. Please let me > know if I need to close this ticket. Thanks. > Now client is able to send RST to STS, but STS(ADFS2.0) failed generating > RSTR because of an empty <wst:Renewing>tag embedded inside RST. ADFS does > not support Token renewing. Why do we have Renewing tag inside issue > request? > > Following is the RST generated by CXF and sent to ADFS2.0. > > > Payload: <soap:Envelope xmlns:soap=" > http://www.w3.org/2003/05/soap-envelope";><soap:Header><Action xmlns=" > http://www.w3.org/2005/08/addressing";> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</Action><MessageIDxmlns=" > http://www.w3.org/2005/08/addressing";>urn:uuid:711a1518-8b69-49fc-a0b8-ac36eccb3400</MessageID><To > xmlns="http://www.w3.org/2005/08/addressing"; xmlns:wsu=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > wsu:Id="Id-24027959"> > https://strts01.ams.dev/adfs/services/trust/13/usernamemixed</To><ReplyToxmlns=" > http://www.w3.org/2005/08/addressing";><Address> > http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Securityxmlns:wsse=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; > xmlns:wsu=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > soap:mustUnderstand="true"><wsu:Timestamp > wsu:Id="TS-1"><wsu:Created>2012-06-06T14:19:05.547Z</wsu:Created><wsu:Expires>2012-06-06T14:24:05.547Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken > wsu:Id="UsernameToken-2"><wsse:Username>GLOBAL\gchoi</wsse:Username><wsse:Password > Type="<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText%22%3Exxxxxx%3C/wsse:Password%3E%3C/wsse:UsernameToken%3E%3C/wsse:Security%3E%3C/soap:Header%3E%3Csoap:Body%3E%3Cwst:RequestSecurityToken><http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText%22%3Exxxxxx%3C/wsse:Password%3E%3C/wsse:UsernameToken%3E%3C/wsse:Security%3E%3C/soap:Header%3E%3Csoap:Body%3E%3Cwst:RequestSecurityToken>">xxxxxx</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken > xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512";><wst:SecondaryParameters><t:TokenType > xmlns:t="http://docs.oasis-open.org/ws-sx/ws-trust/200512";> > http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</t:TokenType><t:KeyTypexmlns:t=" > http://docs.oasis-open.org/ws-sx/ws-trust/200512";> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</t:KeyType><t:KeySizexmlns:t=" > http://docs.oasis-open.org/ws-sx/ws-trust/200512 > ">256</t:KeySize></wst:SecondaryParameters><wst:RequestType> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType><wsp:AppliesToxmlns:wsp=" > http://schemas.xmlsoap.org/ws/2004/09/policy";><wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/08/addressing";><wsa:Address> > https://wkengchoi.global.sdl.corp:8443/doubleit/services/doubleit</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Entropy><wst:BinarySecretType=" > http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce > ">hzeje+CdyWW3V2d6y12WbYZkrSLfMM6E+W4g6Gs+5VI=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm> > http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope > > > > On Tue, Jun 5, 2012 at 3:55 PM, Gina Choi <[email protected]> wrote: > >> Hi Colm, >> >> Thanks for the quick fix. I am planning to check it once your fix >> reflected to 2.6.2-SNAPSHOT. >> >> Gina >> >> On Tue, Jun 5, 2012 at 7:14 AM, Colm O hEigeartaigh >> <[email protected]>wrote: >> >>> >>> The NPE you were seeing is now fixed on trunk, if you want to test with >>> the latest CXF 2.6.2-SNAPSHOT code. You will need to make sure that the WSC >>> has a keystore with a private key to support the KeyValueToken policy. >>> >>> Colm. >>> >>> >>> >>> >>> On Tue, Jun 5, 2012 at 10:14 AM, Colm O hEigeartaigh < >>> [email protected]> wrote: >>> >>>> >>>> Is the client successfully invoking on the STS? In other words, is this >>>> error occurring when the client is sending a message to the STS or to the >>>> WSP? >>>> >>>> Colm >>> >>> -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
