• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 Marcos Ezquerra commented Permalink

I have a problem with this scenario.

I configured all like this document (my WAS and STS isn't over https)
, but I get this error :
WSWS3173E: Error: Did not understand "MustUnderstand" header(s):{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
I check this link http://www-01.ibm.com/support/docview.wss?uid=swg21238420 , but is not a solution for my problem.
Any idea?

2 Neil Readshaw commented Permalink

Do you know if this was an issue between WCF and STS, or from WCF to a WAS web service. It is not clear from your description. Turning on the WCF trace would allow you to inspect that exchange.

3 Paul Gatfield commented Permalink

Thanks for the example. I have several questions.
In our STS setup, the normal url for the token service is http://:9080//TrustServer/SecurityTokenService <br>This does not work with the configuration that you provided for WCF. It requires the protocol "https". <br> <br>I changed the issuer element value in the configuration use port 9443, default SSL port in Websphere for application server on which the STS runs. This results in <br>System.ServiceModel.FaultException: WSWS3173E: Error: Did not understand "MustUnderstand" header(s):{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security <br>from the client perspective. <br> <br>In the Websphere SystemOut.log and trace.log, I see a very similar message with a stack trace. <br> <br>I was wondering if I am correct when I think that (1) with the configuration that is shown in the article, the https protocol must be provided, and, (2) why do you think that the "Must Understand" of the security header is failing? We have enabled application security in our was setup. <br> <br>Very interesting article. thanks. <br>

4 Neil Readshaw commented Permalink

The https requirement is from WCF.

The STS URL in your comment is for tfim's WS-Trust 1.2 endpoint. The one in the article is for WST 1.3. You'll need TFIM 6.2 to get WST 1.3 support and fixpack 3 to fix a couple of minor incompatibilities.

5 John Ngo commented Permalink


Great article! However, I seem to be getting the same error as everyone else. I created a WCF client to invoke the EchoServiceSAML11 test service that came with TFIM: WSSM. The client consumer is configured to validate the UserName token before getting a SAML 1.1 token from the WST 1.3 Trust Server; and the service provider is configured to validate that SAML 1.1 token and issue a Tivoli Access Manager token. The WCF client is calling the echo service over https. However it fails with the message:
WSWS3173E: Error: Did not understand "MustUnderstand" header(s):{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
Any idea's on why I'm getting this?

6 Neil Readshaw commented Permalink


If I have understood the issue correctly, you can successfully use the TFIM STS to obtain a SAML 1.1. token and insert into the request to the WAS-based Echo service, and then the error occurs. Have I understood?
If so, then it could be that the Echo service has not been deployed and configured correctly, because this error can come about when a SOAP message contains the WS-Security header but the service was not expecting it. This could be because the service endpoint has no security or WAS application security is not correctly configured.
Have you verified that the service is correctly deployed by accessing it from the Echo client sample provided with TFIM?
Remember also that TFIM 6.2 + fixpack is required. I haven't tried with the new TFIM 6.2.1 but it should be able to be made to work also.

7 John Ngo commented Permalink


Thank you for your prompt response. I won't be using the EchoService anymore since my project requirements have changed, so I'll be using a WCF Service. I created a simple HelloService and tried to pass it the SAML 1.1 token that my WCF client received from the TFIM STS, however I'm getting the same error: "The header 'Security' from the namespace 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' was not understood by the recipient of this message, causing the message to not be processed.
Is there anything on the WCF service side that I have to configure so it will be able to understand and process that security header?

8 Neil Readshaw commented Permalink


OK - good to hear that you are successfully using TFIM STS to generate a SAML 1.1. token on the service consumer side.
I didn't look at service provider side for SAML 1.1 integration because of the requirements I was addressing when I looked at this. Without having looked at it, I would expect that the service configuration will need a serviceCredentials behaviour to make use of an STS.

Add a Comment Add a Comment