cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <oddbjorn.heim...@accenture.com>
Subject Supporting an IssuedToken as SupportingTokens without transport binding
Date Wed, 22 May 2013 10:18:11 GMT
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

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