Alex
Just reading your last e-mail, First - I can perhaps not give you an answer for all your questions, things you need to tell us are not yet said in this last e-mail. Second - So I would like to know more about your own client and server platform environment, what are you intending to use to make it happen? I guess - it is an extension to the IIS server, isn't it? Or is it a axis2 server running on apache-tomcat on your MS machine? What role plays IIS then? Third - we have long lasting sessions implemented between MS WFC 3.5 client talking to a Apache Axis2-1.2 Server running in scope="soapsession" mode. And it works perfect. BUT - No - in case of IIS running as web-service-engine, I don't know how that shall work, unless IIS forwards web-service-request to an Axis2-Webservice. Does it do that? What is the intention here. So I can talk only for an Axis2-Webservice with long-lasting sessions, and if IIS is more of the party you might have to transfer part of your questions to Microsoft. But think: in general - your platform independence comes by protocol. Jave-Client to MS-IIS-Server is one issue, and MS WCF 3.2 or ASP.NET client to Axis2/Java would be another challenge. Approach: best make client and server first work in each environment, trimmed to long-lasting-sessions and authentication. Then sample and study the protocol use by tcp monitor; If you cannot make long-lasting-sessions and authentication work in a clean MS world or a clean Apache Axis2/Java world how can you estimate to make it work in a heterogeneous MS-Apache world. So as advise - do more simple things first and learn the unique things of each environment, each world. Then study and compare the protocol differences taken by tcp monitor. Reading all your questions, I think it makes most senses to start with long-lasting-sessions, this are sessions where each session-request-thread ends at it's own service-proving-object! Is that true for you as well? Is it what you want? If not - we can stop here. If you have established that, you can think how to authenticate the requesting party further to avoid ongoing authentication needs within each recurring request. 1. Soap sessions, authentication, authentication on a per request from the same user-session - Then you need long -lasting-sessions and hence you have to add scope="soapsession" to your service.xml, add a init() and a (destroy() method to your service-class, 2. WS-Addressing needs to be engaged on client and server side 3. Take tcp monitor and see that the first response returns a servicegroupId in the Soap header 4. Return this servicegroupId in the soap header with each consecutive request to the server, that way, you will hit always the same instance of the service-providing-object, identified by the servicegroupId 5. Do not forget to change the timeout value in the axis2.xml file server side from 30000 ms to what you think is a proper timeout within which at least a next request from your user-session-thread has to come in to this instance of a service providing object, Unless the destroy() method in your service-providing-object is called by the axis2-engine, invalidating your axis2-web-service-object (object meant as instance of your service providing class identified be the servicegroupId) So far for long lasting sessions. Scope="soapsession" guarantees that each user can have from its PC several session-threads and that each session-thread talks always to the same object (instance of a class) The object can then be a placeholder for any beans connecting you further, such as HP WSIT beans to go to OpenVMS Legacy Servers, calling JNI through the JVM into the C and C++ RTL's from Java etc etc. As part of the very first call you need to do the authentication! The question is now: who transfers the NTLM authentication credentials? What are the NTLM pieces of information transmitted/exchanged? Do you understand the NTLM protocol? Also - NTLM authentication is a Microsoft proprietary authentication protocol; hence it has a legal aspect! Hence to find out how eligible it is to use it through Apache Axis2 you need to contact Axis2 developers/management/legal-department. But technically speaking: NTLM is a protocol which takes place in > 1 interaction between client and server. Hence: where and who shall this pieces be transferred, who takes ownership of this transfer? So you may well establish first your service-providing-object and then in a second stage start the NTLM authentication-sequence on the server side. This in absence of a better know-how from my side. Maybe somebody else can better help you on that. Considering a different but not NTLM authentication will bring you closer to WS-Security* more suitable and open-source-like then anything else; and here is a lot to say, go for it in appropriate documentation, presentations and standard documents; Also in this regard, Microsoft helped a lot to "get it right for Microsoft", helping defining the security-standards for WS-Security e all. Maybe there is some goodies in that as well. We do long-lasting-sessions with a basic authentication, that is we pass username and password today in clear text and will next change to a DIGEST-Encrypted schema for the password. Knowing that DIGEST isn't real secure. Request: 1. On a firts request to login, axis2 engine creates an instance, an object of the service-providing-class, a real object, and calls init() on it, and then in turn calls login() on it which does the authentication. In our case, login(OMelement e) gets called and receives within the OMElement - username and password, this among other initial things, and then authentication is done by OpenVMS UAF 2. Request returns and if return args signals a failure through exception, as i.e. password is not right, login is called a second and a third time ... 3. If password is right user-methods are then called 4. And all is done by the same long lasting service-providing-instance, a real object. 5. Also to know is that HTTP Headers must exact match axis2-service expectations! Make this example run first using java-axis2-client and java-axis2-service running in scope="soapsession", and monitor the HTTP header. If you later turn to a different client implementation (as in our case) to MS VS WCF 3.5 client-stubs, you need to add the servicegroupId SOAP Header and you need to add the additional bits to the HTTP header in your message-interception-technique to make axis2-engine think it is an axis2-client calling in. 2) If I create several soap clients in one process, they all use the same TCP connection. Thus even if (1) gets resolved, mixing requests from different soap sessions will break the authentication. NO - If you manage to setup your client to web service with long lasting sessions scope="soapsession" then I guarantee you that one client process can make multiple connections; Why? Because - as long as each request transfers its own unique servicegroupId in the header - as long each request will hit its own unique service-providing object. That is to say - dispatching a request to the service-providing-object is then done slightly different than Axis2 schoolbooks for beginners teach you. And it works real great! The issue is how to make i.e. a MS WCF client sniffing in the extra soap-header called servicegroupId. (Answer: add a behavior object to your client and make it intercepting message-requests and message-responses) But if your client is Axis2-java, then this is done much more simple. AND Again: where exactly the authentication of the request is done, is a other bier. And if somebody more know-ledged to the subject requested, I am eager to learn! BTW: we have to adopt WS-Security* e all over time into our established long-lasting-session environment passing request-messages from WCF Client to Axis2/J Services and many thing is absolute unclear to me right now. Joswef.Stadelmann @axa-winterthur.ch Von: Alex A [mailto:a...@alex-andr.org] Gesendet: Donnerstag, 25. November 2010 13:19 An: java-user@axis.apache.org Cc: Martin Gainty Betreff: Re: Is this list completely dead? Ah, great, there is some life here :) Here is my questions again, if all questions can't be answered, it would be great to have at least some answers or ideas. Thanks! - I need to have several simultaneous connections form one client to the same SOAP service. - Credentials, used in all connections are NOT the same - different users and possibly even different authentication modes. But I would like TCP connections to be preserved - especially for NTLM authentication so it does not need to do 3-step auth every time. - If all three (Basic, Digest, NTLM) enabled on the server side (IIS), how can I force choosing particular type on the client side, per connection? authenticator.setAuthSchemes() does not seem to work. Also, can someone explain if options.setProperty(WSClientConstants.CACHED_HTTP_STATE, new HttpState()); is relevant, and what is the package name for WSClientConstants? (this is taken from http://axis.apache.org/axis2/java/core/docs/http-transport.html) The behavior I see right now has the following problems (working with Exchange server via EWS): 1) Even in case of just one soap session, with NTLM authentication, every new request initially gets 401 and has to re-authenticate. Keeping in mind that full request's xml is being sent over to server for authentication, it's thrashing the performance. With NTLM, TCP connection got to be authenticated, not request. 2) If I create several soap clients in one process, they all use the same TCP connection. Thus even if (1) gets resolved, mixing requests from different soap sessions will break the authentication. 3) I am unable to force-select the Authentication method I want (if all available on the server). Thanks, ~ Alex. On 11/24/2010 7:44 PM, Martin Gainty wrote: always..whats your question?? Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Date: Wed, 24 Nov 2010 16:34:43 -0500 > From: a...@alex-andr.org > To: java-user@axis.apache.org > Subject: Is this list completely dead? > > I wonder if anyone ever responds to any user's questions posted to this > list? > > Cheers, > ~ Alex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org >
