That wsu namespace that is on that UsernameToken in the 2nd example is there for wsu:Id. The wsu:Id is only needed if something will reference the element. You have nothing referencing the element, so it is not required.
If you were getting an error because the security handler didn't like the fact that the wsu:Id was missing, you would get a SoapSecurityException, not a MustUnderstand check.
A MustUnderstand check means that you have sent a header for which no handler in the runtime has marked as processed. Either there is no handler registered to handle it or no registered handler marked the header. For security headers, this usually means that there are no WS-Security constraints applied.
You can verify that there are no WS-Security constraints applied by sending a message with no Security header.
If you send a message that includes a Security header like your 2nd example?
Do you have security constraints on you client for responses? You will get this same error if you have no constraints for responses but the server sent a Security header in the response.
This is what I would do:
1) Enable a WS-Security trace on the WAS server
com.ibm.ws.webservices.wssecurity.=all:com.ibm.wsspi.wssecurity.=all:com.ibm.ws.wssecurity.=all:com.ibm.websphere.wssecurity.=all:com.ibm.xml.soapsec.=all:com.ibm.ws.webservices.trace.=all:com.ibm.ws.websvcs.trace.=all:com.ibm.ws.wssecurity.platform.audit.=off:com.ibm.ws.webservices.multiprotocol.AgnosticService=all:com.ibm.ws.websvcs.utils.SecurityContextMigrator=all
2) Restart the server
3) Send the message from the client
4) Search the trace for 'bound http'.
4a) You should see the Inbound HTTP SOAP Request
4b) search again
4c) You should see Outbound HTTP SOAP Response
4ci) Does the response have the expected response or a fault?
4cii) If the response is a fault, then you have a server issue
4cii) If the expected response, does the response contain a Security header?
4ciii) If yes, then the MustUnderstand check came from the client and you most likely need to apply security response constraints to your client.
5) If, in step 4, you determined that you have a server issue, search backwards in the trace for something that looks like this (on the current thread):
WSSecurityCon 3 isServerSide == true
WSSecurityCon 3 No PolicyType Binding
5a) If you see this, then you do not have security constraints applied to your provider application. Here are some instructions for applying a UsernameToken policy in WebSphere (assuming that your app is JAX-WS):
https://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_stand_alone_security_token.html
And for those that delete my posts because they have links:
Configuring a policy set and bindings for a stand-alone security token (UsernameToken or LTPA Token)
You can secure web services by configuring the message-level WS-Security policy set and bindings for a stand-alone security token that is either a Lightweight Third Party Authentication (LTPA) token or a Username token.
Before you begin
This task assumes that the service provider and client that you are configuring are in the JaxWSServicesSamples application. See the documentation on accessing samples to learn how to obtain and install this application. Specify the following trace specification on your server to enable you to debug any future configuration problems that might occur.
=info:com.ibm.wsspi.wssecurity.=all:com.ibm.ws.webservices.wssecurity.=all:
com.ibm.ws.wssecurity.=all: com.ibm.xml.soapsec.=all: com.ibm.ws.webservices.trace.=all:
com.ibm.ws.websvcs.trace.=all:com.ibm.ws.wssecurity.platform.audit.=off:
If LTPA tokens are used, you must enable the application security on the application servers that are used for both the client and the service.
About this task
This topic describes how to configure a WS-Security policy set and provider bindings for a Username token or an LTPA token. For simplicity, this procedure demonstrates how to remove the timestamp, digital signature, and encryption attributes from the policy; however, you might want to include these attributes in your final configuration. To learn more, see the documentation on configuring a policy set and bindings for Asymmetric XML digital signature or XML encryption with client and provider application specific bindings.
In this task, default provider general bindings are used for the provider application to consume the tokens. If a caller configuration is required, an application-specific binding will be added for the provider.
Procedure
Create the custom policy set.
In the administrative console, click Services > Policy sets > Application Policy sets.
Click New.
Specify Name = OneTokenPolicy.
Click Apply.
Under Policies, click Add > WS-Security.
Edit the custom policy set
Remove digital signature, encryption, and timestamp.
In the administrative console, clickWS-Security > Main Policy.
Deselect Message level protection.
Click Apply.
Add the UsernameToken or LTPA token.
Under Policy details, click Request token policies.
Select Add Token Type.
If you want to use a UsernameToken, select UserName. If you want to use an LTPA token, select LTPA.
Token name=myToken.
Click OK.
Configure the client to use the OneTokenPolicy policy set.
In the administrative console, click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service client policy sets and bindings.
Select the web services client resource.
Click Attach Policy Set.
Select OneTokenPolicy .
Create a custom binding for the client.
Select the web services resource again.
Click Assign Binding.
Click New Application Specific Binding to create an application-specific binding
Specify the bindings configuration name. name: oneTokenClientBinding
Click Add > WS-Security
If the Main Message Security Policy Bindings' panel does not display, select WS-Security.
Edit the custom binding for the client.
Edit the identity token generator to send the identity username.
Click request:myToken.
Click Apply.
Click Callback handler. User name=(yourUserid) Password=(yourPassword)
Avoid trouble Avoid trouble: This is a userid/password that is valid on the user registry on the provider's system. If you are using LTPA tokens, the userid/password must be valid on both the consumer and provider registries.
(Optional) If configuring a UsernameToken, add the following WS-Security custom properties:
*com.ibm.wsspi.wssecurity.token.username.addNonce=true
*com.ibm.wsspi.wssecurity.token.username.addTimestamp=true
These custom properties are added because they are specified on the UsernameToken consumer default general bindings. If we do not specify those properties here, you will either need to remove those properties from the default provider general bindings or create application-specific bindings for the provider that does not include those properties.
Click OK.
Click Save
Configure the provider to use the OneTokenPolicy policy set.
In the administrative console, click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service provider policy sets and bindings
Select the web services provider resource (OneTokenPolicy)
Click Attach Policy Set.
Select OneTokenPolicy
Note: Since no bindings are attached to the provider application, it will use the default provider general bindings for the token consumers.
(Optional) If you want to create a Caller configuration for the provider, create custom bindings for the provider.
Select the web services provider resource again.
Click Assign Binding
Click New Application Specific Binding to create an application-specific binding
Specify Bindings configuration name:oneTokenProvBinding
Click Add > WS-Security
If the Main Message Security Policy Bindings' Panel does not display, select WS-Security
(Optional) If a Caller configuration will be created, edit the custom bindings for the provider.
Click Caller > New. Name: myCaller.
If using a UsernameToken, enter the following:
Caller identity local name: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
If using an LTPA token, enter the following:
Caller identity local name: LTPAv2
Caller identity local URI: http://www.ibm.com/websphere/appserver/tokentype
Click OK.
Click Save to save your configuration changes.
Restart the client provider.
Stop the client and the provider
Restart the client and the provider
Test the Service.
Point your web browser at the JaxWSServicesSamples: http://localhost:9080/wssamplesei/demo
Avoid trouble Avoid trouble: Make sure you provide the correct hostname and port if your profile is not on the same machine or the port is not 9080.
Select Message Type Synchronous Echo
Make sure Use SOAP 1.2 is not selected
Enter a message and click Send Message. The sample application should reply with JAXWS==>Message.
Results
The JaxWSServicesSamples web services application is configured to generate and consume a UsernameToken or LTPA token in the request message.
