cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Supporting an IssuedToken as SupportingTokens without transport binding
Date Wed, 22 May 2013 14:54:31 GMT
This will be be fixed in CXF 2.7.6:

https://issues.apache.org/jira/browse/CXF-5031

Colm.


On Wed, May 22, 2013 at 11:18 AM, <oddbjorn.heimdal@accenture.com> wrote:

> Hi,
>
> I have a use case with the following policy:
>
> <sp:SupportingTokens>
>    <wsp:Policy>
>    <sp:IssuedToken sp:IncludeToken="
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
> ">
>       <sp:RequestSecurityTokenTemplate>
>          <wst:TokenType>
> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
> </wst:TokenType>
>          <wst:KeyType>
> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</wst:KeyType>
>       </sp:RequestSecurityTokenTemplate>
>       <wsp:Policy>
>       </wsp:Policy>
>      </sp:IssuedToken>
> </wsp:Policy>
> </sp:SupportingTokens>
>
> This will only work if I also include a transport binding. This is
> probably due to failing the isRequestor check at line 133 in the
> TransportBindingHandler, which results in skipping the crucial
> handleNonEndorsingSupportingTokens method for the default transport binding.
>
> I see that there has been similar limitations for Kerberostokens which has
> been fixed with CXF-4786. Is there a reason for this limitation or can we
> simply add the handleNonEndorsingSupportingTokens method also for the case
> of the default transport binding?
>
> Best regards,
>
> Oddbjørn
>
> ___________________________________________________________________________________________
> Oddbjørn Heimdal
> Accenture Technology Consulting -  Security
> Snarøyveien 30, P.O. Box 363, 1326 Lysaker, Norway
> Mobile: +47 99 72 19 12
> Email: oddbjorn.heimdal@accenture.com<mailto:
> oddbjorn.heimdal@accenture.com>
>
>
> ________________________________
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and
> its affiliates, including e-mail and instant messaging (including content),
> may be scanned by our systems for the purposes of information security and
> assessment of internal compliance with Accenture policy.
>
>
> ______________________________________________________________________________________
>
> www.accenture.com
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

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