I'm trying to secure an Axis2 (+Rampart) message to a proprietary WS-Security enabled server. The message must contain a signed SAML token. I'd like to ask for opinion/help on the following issues which I observed:
1) WS-SecurityPolicy (for WSDL policies) defines <sp:IssuedToken> if Axis is supposed to contact the STS server and <sp:SamlToken> if the token is obtained by alternative means. However Axis2 doesn't seem to support/understand <sp:SamlToken> that is what I need. I'm working around this by using <sp:IssuedToken> instead and setting my token with RampartMessageData.KEY_CUSTOM_ISSUED_TOKEN to the Options for ServiceClient.
This works but unfortunately my WSDL is not following the standard strictly (should use <sp:SamlToken> instead), that is not desirable.
2) I want to sign the custom SAML token with the "message signature". So in WSDL I use <sp:SignedSupportingToken>. Axis can't sign it because the token doesn't have a wsu:Id (or Id) attribute, but has ID only. Also the token is itself signed so I can't afford modifying it.
I tried signing the whole Security header or even <soap:Headers> but the problem here is that Axis never includes the "enveloped-signature" transform, so such signature can't be verified by the server. WS-Security spec suggests that "enveloped-signature" SHOULD NOT be used, so I understand why Axis behaves that way.
In theory it seems that <SecurityTokenReference> and STRTransform can solve the problem here, but I can't find any way to make Axis use these.
3) When generating the message signature, I need <ds:KeyInfo> like this (since my SAML token carries the public key that corresponds to the signature):
Again, I just couldn't generate such key info with Axis2. Code reading showed that this i just not supported at least with the AsymmetricBindingBuilder (yes, I use <sp:AsymmetricBinding>).
Thanks, for any comments on this!
Joined: Feb 14, 2011
Well, for the record: it's clear for me now that Rampart 1.5.1 just doesn't support the WSS: SAML Token profile. This easily explains 1) and 3) and also the lack of ability to do the alternative token reference (SecurityTokenReference + STR dereference transform) in 2).