cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: STR-Transform for IssuedToken in WS-Policy
Date Thu, 16 Jan 2014 10:17:57 GMT
Correct, CXF currently is only designed/tested to work with STS-issued SAML
HolderOfKey + Bearer Assertions.

If I am understanding you correctly, the scenario is that you have an STS
issuing a (signed?) SenderVouches Assertion, and you expect the CXF client
to generate a new Signature, that signs the SAML Assertion via a
STR-Transform. Is this correct?

I you send the SecurityPolicy you are using I can take a look to see if
it's easy to implement.


On Thu, Jan 16, 2014 at 5:42 AM, bimjoeipa

> Hi,
> We are currently using a particular ESB which requires that SAML tokens
> with
> the Sender Vouches (SV) confirmation method must have a STR-Transform
> signature in the security header.  We use an STS that generates signed SAML
> SV Tokens (we are using SV because we are exchanging a proprietary Single
> Sign on Token for a SAML token).
> I debugged
> org.apache.cxf.systest.wssec.examples.saml.SamlTokenTest.testSymmetricSV()
> compared with
> org.apache.cxf.systest.wssec.examples.saml.SamlTokenTest.testSymmetricIssuedToken()
> (I realise this example is HOK) and from what I can tell, it basically came
> down to sp:IssuedToken's can't generate STR-Transforms, but the
> sp:SamlToken
> does.
> Does this sound correct, does CXF have a technical limitation that it won't
> generate a STR-Transform for sp:IssuedToken's?  I understand that
> IssuedTokens are signed, so don't technically need another signature, but
> our ESB is a bit stubborn in this area...
> Thanks,
> Joel
> --
> View this message in context:
> Sent from the cxf-user mailing list archive at

Colm O hEigeartaigh

Talend Community Coder

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