Well, I’m working with a large existing code base, so extending SAMLTokenSignedAction is most likely not an option, but I’ll look it over and see if it’ll work for me.
In the meantime I’ll look over the WSHandler code and look at setting up a SecurityActionToken. Thanx! Stephen W. Chappell From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Thursday, June 18, 2015 5:58 AM To: [email protected] Subject: Re: WSSecSignatureSAML Could you not extend or change the SAMLTokenSignedAction to do what you want? Failing that, you need to set up the correct SecurityActionToken as WSHandler does, and use this instead to populate WSSecSignatureSAML. Colm. On Thu, Jun 11, 2015 at 8:11 PM, <[email protected]<mailto:[email protected]>> wrote: As usual, I see that my question goes pretty far beyond what I thought it did. I have a bit of code that, after issuing a SAML assertion, sets up a WSSecSignatureSAML object in order to sign the message with the private key associated with the assertion. It set up the WSSecSignatureSAML by pulling info from a RequestData object, like the WSSConfig, signature user, relevant algorithms, etc. And it also pulled out the signature parts from RequestData and set them into the WSSecSignatureSAML via setParts() – but that method doesn’t exist anymore. For that matter, there’s no way to set a WSSConfig either. So is there a new/better/different way to set the config and the parts for the WSSecSignatureSAML object, or should I be using something different now? Thanx, Stephen W. Chappell -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
