03-26-2010 07:41 PM
However, the bit that really confusing me is the authentication. In the official doc, the magic line reads "exec.Credentials = System.Net.CredentialCache.DefaultCredentials;" . My guess is that it will grab the current windows logged in user and pass something to web service, so TRIM WS will know who sends the request. But what exactly is this step doing? what and what format of this credential information got passed, will they be part of soap body, or in the HTTP request header?
And then will TRIM WS use this credential to connect to TRIM workgroup server, and only retrieve the records that this windows user can access based on its permissions inside TRIM?
The biggest problem for me now is this frontend app runs on linux, and getting windows credentials is not that easy. The best I can do at the moment, is let user type in windows login/password and do a NTLM authentication when sending the soap request. I might be naive here, but would this actually be sufficient to do what System.Net.CredentialCache.DefaultCredentials does? :)
03-27-2010 02:14 PM
That line of code is telling the client side web service proxy to execute in the context (and with the credentials) of the current user. It sets the security context of the HTTP request.
The credentials will allow you to access the web service, which will then pass those credntials on over to TRIM and execute the request in the context of that account.
When you're using SoapUI you're probably specifying your own username and password in the properties of the envelope. What usually happens is that the person designing the SOAP requests via SoapUI forget that what they are doing may not work in the context of the account a user might pass through, so be sure you embed a lot of error trapping in your java classes.
You're going to have to work through how to pass through windows credentials via your java proxy classes. I've heard in the past that it required the implementation of an SSRS approach when the web service is secured on windows with NTLM, though that was a ways back and things may have changed.
I hope this helps.
03-30-2010 03:01 PM
01-22-2014 04:10 PM
We've been unable to resolve the error experienced on our Primary Web enabled server.
As a workaround, we've installed a fresh web service and web client on a secondary server.
Should I be concerned if the Web Service and Web Client only load on the workgroup server when using localhost in the URL?
If we replace localhost with the servername, then it won't load.
Using the servername works fine when remotely accessing the web client or service from my own personal desktop PC.