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. Colm. On Thu, Jan 16, 2014 at 5:42 AM, bimjoeipa <[email protected]>wrote: > 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: > http://cxf.547215.n5.nabble.com/STR-Transform-for-IssuedToken-in-WS-Policy-tp5738605.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
