JBOSS AS 7.1.1 apache cxf 2.4.6 ws-security tokens

[crumbs]

Hi,

I am using JBOSS 7.1.1, with apache cxf 2.4.6.

I followed the instructions in this link to the dot:

https://docs.jboss.org/author/display/JBWS/WS-Security

But I get errors like:

javax.xml.ws.soap.SOAPFaultException:These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts

javax.xml.ws.soap.SOAPFaultException:These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedElements

javax.xml.ws.soap.SOAPFaultException:These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RequiredParts

Is there any additional setup required like installing an STS? And additional code to communicate with the STS?

This above link does not mention anything like that.

Is there some clear documentation on activating an STS? Or is it a matter of including a dependency in the MANIFEST.MF file?

I have already included the dependencies mentioned in the link, such as org.apache.cxf, etc.

Thanks so much,

Indira

[asoldano]

You don't need a STS for the examples mentioned on the page above. I suggest having a look at the corresponding examples included in the binary distro, try running the testcases, etc.

[crumbs]

Thanks so much, Alessio.

I could not figure out where the particular error is coming from.  There was no reference to http in the policy.://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

There could be something wrong with the policy.  So I abandoned the policy approach and switched to the wss4jInterceptors approach and the signing is working now.

Is the STS required for SAML tokens? Still using JBOSS 7.1.1 and cxf 2.4.6

Thanks again,

Indira

[asoldano]

It really depends on how you get access to the SAML tokens. Using STS is *a* way for getting them.

[crumbs]

Thanks, Alessio.

I moved to JBoss 7.2 and used the SamlCallbackHandler to create a SAML token.

I also got the policy approach to work.  So it is all good now.

Except that the SAML assertion is not getting signed:-)

Timestamp, and body are getting signed, as per my policy.  But the saml:Assertion which needs to be signed as well, is getting left out of the signature block.

-Indira

[crumbs]

The saml assertion has a signature inside the saml assertion. In addition to this, the saml assertion needs to be signed as well, and should be referenced in the Signature block of the header. The second part is what is not happening.

-Indira

[crumbs]

The signed parts policy looks kind of like this:

<sp:SignedParts>

<sp:Body/>

<sp:SignedParts>

<sp:SignedElements>

     <sp:XPath>

...........................Timestamp>

     </sp:XPath>

     <sp:XPath>

.     ......................BinarySecurityToken

     </sp:XPath>

     <sp:XPath>

          /env11:Header/wsse:Security/saml:Assertion>

     </sp:XPath>

     <--There is also one for SOAP 1.2>

     <sp:XPath>

     /env12:Header/wsse:Security/saml:Assertion>

     </sp:XPath>

</sp:SignedElements>

The Body, Timestamp, and BinarySecurityToken are getting signed.  But not the saml:Assertion.

[asoldano]

I believe xpath references in SignedElements assertions are not expected to work with elements that are actually added by cxf/wss4j itself in the wsse:Security header. The fact you want the SAML token to be signed should come from the effective policy. Can you paste your actual policy? Is the SAML token specified in there within e.g. a *Signed*SupportingToken? Consider having a look at this page http://coheigea.blogspot.it/2011/04/saml-support-in-cxf-240.html which might be of some help.

[crumbs]

Alessio,

I looked at the link you sent.

I don't have internet at my workstation so I will try to reproduce the policy outline here.

<Policy HolderOfKey>

.....

<AsymmetricBinding>

    <InitiatorToken>

          <SamlToken>

          ........

          </SamlToken>

     </InitiatorToken>

</AsymmetricBinding>

<sp:SignedSupportingTokens>

     <sp:X.509Token>

       ..................

     </sp:X.509Token>

</sp:SignedSupportingTokens>

....

</Policy HolderOfKey>

This might only account for the signature within the saml assertion block.  Looks like the authors of the policy meant for the saml to be signed externally using the xpath reference in the signed elements policy.

Thanks,

Indira

[crumbs]

http://coheigea.blogspot.it/2011/04/saml-support-in-cxf-240.html

In the "DoubleItSaml2AsymmetricPolicy" example:

"One thing to note is that as the SAML Assertion has a subject confirmation method of "sender-vouches", the client will automatically add the quality-of-service requirement that the signature which covers the SOAP Body will also cover the SAML Assertion."

In the policy my client code is following, the confirmation method is "holder of key".

Also, in my service provider's policy, the initiator token is the saml token, the signedsupportingtoken is the X.509 token, and they are expecting the saml to be signed via signed elements policy fragment for the inputs.

I am trying to see if I can tweak the effective policy to also sign the saml assertion.

<Policy HolderOfKey>

.....

<AsymmetricBinding>

    <InitiatorToken>

          <SamlToken>

          ........

          </SamlToken>

     </InitiatorToken>

</AsymmetricBinding>

If I change this to a saml token, I see a nullPointerException from AsymmetricBindingHandler.doSignature(.....)

<sp:SignedSupportingTokens>

     <sp:X.509Token>

       ..................

     </sp:X.509Token>

</sp:SignedSupportingTokens>

....

</Policy HolderOfKey>

Or perhaps use an interceptor to sign the saml.  But it appears that using Wss4jInterceptors and jbossws-cxf at the same time may be problematic.

[crumbs]

Regarding Saml HOK assertion not being signed in JBoss 7.2:

I see this warning

WARNING: No assertion builder for type ...ProtectTokens registered

Could this be causing the Saml assertion to not be signed?