This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Steps to reproduce: - Create 1st Web Application with Web Service. - Enable message level security for this WS using UserNameToken profile. - Deploy the 1st Web Application. - Create 2nd Web Application with Web Service Client for WS from 1st app. - Create Servlet in 2nd web app and add in it the code to invoke some operation of secured WS. - Enable message level security for web service client using UserNameToken profile (set some not valid username and password). - Change the Web Service Client Security Configuration: just set the username field empty. - Deploy the 2nd web application and run the servlet (sometimes exception throws in output but application deployed successfully). - Notice that invocation of secured operation passed without any error. - In AS log we can see that for invocation username 'testuser' was used but we did not set this username.
Created attachment 38234 [details] Deployment output
Created attachment 38235 [details] AS log
I can't reproduce the problem. The exception in the deployment log indicates there is some issue connecting to the access manager. The behaviour you saw might be a side-effect of that. Please try to come up with a reproducible step for creating the exception you saw in the deployment log.
It looks like the empty username corrupted the agent file for the client under the amflatfiledir/amserver/idrepo/agent directory. I think this is what caused the exception at deployment time. It also looks like the AM authentication provider simply uses the default client agent file (wscWSC) which contains the default testuser. I'll file a bug against the access manager. Meanwhile, on our side, I'll append an empty space to the empty username to plug the security leak.
Checked in a fix to prevent users from exploiting this security hole caused by an empty username.
Verified.