cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Problem with loading Apache CXF STS with UT authentication
Date Wed, 06 Jun 2012 16:17:13 GMT
> 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 <ginachoi88@gmail.com> 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 <ginachoi88@gmail.com> 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 <coheigea@apache.org>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 <
>>> coheigea@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message